Synaser a prace s nim

Otázka od: tomsir1.edu@mail.cez.cz

10. 8. 2004 20:14


Ahoj,
snazim se tu nastudovat praci se synaser-em.
V podstate mi jde o to, byt schopen komunikovat s mobilem. Umim otevrit
port, nastavit parametry prenosu a poslat AT prikaz podle prikladu.
Nicmene nemam poneti, jakym zpusobem mam zpracovat tu cast, kde je napsano
:

    // you are now connected to a modem at +420 ...
    // you can transmit or receive data now

Zrejme se bude jednat o nejakou smycku, kdy budu posilat data a cekat na
odpoved, ale priznam se, ze si to nedovedu predstavit.
Proto bych chtel poprosit o nejaky funkcni priklad, pripadne o odkazy na
ne.

Delal jsem jiz nejake programy pro komunikaci s mobilem, ale pouzival jsem
komponenty tretich stran, kde byla napr. udalost OnReceive, ktera se
vyvolala po prichodu dat, muze se totiz stat, ze napr. pri vyzvaneni dojde
k prijmu dat (retezec 'RING') ... jak toto osetrit pri pouziti synaser ?


Doufam ze to neni moc zmatene ... a diky
Radek




Odpovedá: Lukas Gebauer

10. 8. 2004 21:39

> snazim se tu nastudovat praci se synaser-em.
> V podstate mi jde o to, byt schopen komunikovat s mobilem. Umim otevrit
> port, nastavit parametry prenosu a poslat AT prikaz podle prikladu.
> Nicmene nemam poneti, jakym zpusobem mam zpracovat tu cast, kde je napsano

Jsou tu dve naprosto odlisne veci.. jednak je tam metoda AtCommand, ktera
slouzi na posilani jednoduchych AT prikazu, tako "ATZ", atd. proste AT
prikazy, ktere konci bud odpovedi OK, nebo ERROR.

Pak je tam metoda ATConnect, ktera slouzi na poslani takoveho AT prikazu,
ktery zpusobi navazani datoveho spojeni s nejakym dalsim modemem. To muze
byt bud prikaz 'ATD', nebo treba i 'ATA'. Po skonceni tohoto prikazu mas
bud chybu spojeni, nebo je spojeni navazano, a vse co posles od te chvile
do modemu, bude predano modemu na druhe strane linky, a naopak.

> Delal jsem jiz nejake programy pro komunikaci s mobilem, ale pouzival jsem
> komponenty tretich stran, kde byla napr. udalost OnReceive, ktera se
> vyvolala po prichodu dat, muze se totiz stat, ze napr. pri vyzvaneni dojde
> k prijmu dat (retezec 'RING') ... jak toto osetrit pri pouziti synaser ?

Synaser je jiny nez ostatni. Komponent, ktere uzivaji udalosti, tech jsou
mraky. Opravdu jsem nepotreboval psat to co uz bylo mnohokrate napsano.
Synaser pouziva zcela jinou filozofii pouzivani, a tim vytvari
alternativu k jiz existujicim komponentam. At si kazdy vybere to co mu
vice vyhovuje.

Pochopitelne, principy pouzivani Synapse a Synaseru jsou popsany.
Napriklad vysvetleni, jak cist data, najdes na wiki strankach Synapse:
http://synapse.ararat.cz/wiki/index.php?page=Article014

jednoduse, zadny event oznamujici prichod dat v Synaseru nenajdes. neni
tam! Kdyz chces precist nejaka data, specifikuj jaka data a precti si je.
Tvuj program tyu data bud precte z bufferu jiz prijmutych dat, nebo se
jednoduse beh proghramu zastavi do te doby, nez pozadovana data prijdou.
(pochopitelne mas moznost definovat timeout na celou operaci.)

Takze pokud chces cekat na zvoneni, neni nic jednodusiho, nez v nejake
smycce periodicky vpolat pozadavek na precteni retezce dat zakoncenych
odradkovanim. Nastav si nejaky rozumny timeout, a kdyz dostanech chybu
timeoutu, operaci suse zopakuj do te doby, nez prijmes nejaka data. Kdyz
se ti podari neco prijmout, tak se podivas, jestli data obsahuji RING.

Jednodusi je ale primo sledovat property 'ring', ktera je k tomuto
urcena.  


--
Lukas Gebauer.

E-mail: gebauerl@mlp.cz
WEB: http://www.ararat.cz/synapse - Synapse Delphi and Kylix TCP/IP Library



Odpovedá: Erik Salaj, Winsoft

10. 8. 2004 23:00

> Synaser je jiny nez ostatni. Komponent, ktere uzivaji udalosti, tech jsou
> mraky. Opravdu jsem nepotreboval psat to co uz bylo mnohokrate napsano.
> Synaser pouziva zcela jinou filozofii pouzivani, a tim vytvari
> alternativu k jiz existujicim komponentam. At si kazdy vybere to co mu
> vice vyhovuje.

vecsina komponentov AIK umoznuje pouzivat tak udalosti ako aj cakanie
s timeoutom. Obidva tieto moznosti maju svoje vyhody aj nevyhody
a obidva su podporovane Windowsom.

Treba si uvedomit, ze kym udalosti su nativne pre seriovu komunikaciu
(t.j. priamo podporovane hardwerom), timeouty su uz cisto softwerova
zalezitost a preto viac zatazuju system. Nema preto vyznam pouzivat
ich aj tam, kde to nie je vyhodne. Dnes som robil program, ktory cita
sucasne zo 64 COM portov (pomocou USB-RS232 prevodnikov)
udaje a zapisuje ich do suboru. Neviem aky vyznam by malo komplikovat
riesenie pomocou timeoutov, ked mozem vyuzit udalost a udaje jednoducho
precitat ked pridu (a ja neviem vopred kedy pridu, ani ich dlzku, viem
len to, ze su to hexakody ukoncene urcitymi znakmi):

procedure TForm.ComPortRxChar(Sender: TObject);
begin
  Spracuj(TComPort(Sender).ReadString);
end;

Erik


Odpovedá: Lukas Gebauer

11. 8. 2004 14:50

> vecsina komponentov AIK umoznuje pouzivat tak udalosti ako aj cakanie
> s timeoutom. Obidva tieto moznosti maju svoje vyhody aj nevyhody
> a obidva su podporovane Windowsom.

To je trosku jina pisnicka... kdyz nekdo napise seriovou komponenty,
ktera je porad v principu udalostmi rizena, a pripise k tomu kod, kterym
navic simuluje blokujici volani, tak je to porad pochopitelne o necem
uplne jinem, nez kdyz se ti kod chova blokujicim zpusobem od uplneho
zacatku. Hlavne prave z hlediska efektivity. Je to stejne, jako kdybych
blokujici kody Synaseru obalil tak, aby volal udalosti. Jde to, ale
nebude to nikdy tak efektivni jako kdyz bude kod psany od zacatku jako
udalostmi rizeny.

> Treba si uvedomit, ze kym udalosti su nativne pre seriovu komunikaciu
> (t.j. priamo podporovane hardwerom), timeouty su uz cisto softwerova
> zalezitost a preto viac zatazuju system.

Nestras nam tu lidi! Sam dobre vis, jak to ve skutecnosti probiha...

Hardware vyvolava tak maximalne preruseni... ale to ovlada driver
serioveho portu. Ten to vzdycky prechroustava, krmi do vlastnich
internich bufferu, a az tento driver ridi komunikaci s aplikaci.
Blokujici a neblokujici volani je ciste a jen o komunikaci s driverem a
ne o komunikaci s hardwarem.

U udalostmi rizenem programovani serioveho portu dochazi k tomu, ze
jakmile jsou nejaka data k dispozici, je volan tvuj program, aby si data
precetl z bufferu a nejak zpracoval. Chci li precist treba souvisly
kilobajt dat, bude muj program zavolan pravdepodobne hned nekolikrat, a
moje obsluzna rutina si musi vsechna ta data pri kazdem volani nekam
ulozit a zjistovat, jestli nahodou uz nejsou vsechna. V nejhorsim moznem
pripade, kdy je udalost volana pro kazdy prijaty bajt dat zvlast
(nastesti to se nestava...) se muj program docela namaka...

Zatimco blokujici zpusob udela to, ze zada pozadavek na prijmuti
kilobajtu dat, a muj program se vesele uspi. Nic v tu chvili nedela,
nezere vubec zadny strojovy cas... driver si sam do sebe vesele prijima
data, a az jich ma mnou pozadovany kilobajt, tak muj program bude
driverem probuzen, a je mi predan prave kolibajt dat. kdyz do urcite doby
pozadovana data neprijou, je muj program probuzen s chybou.

Nejak tu vic prace ohledne timeoutu nevidim, takze proc by to melo byt
vice narocne? Ba naopak!

Takze nestras, ze by blokujici kod mel byt nejaky pomalejsi, nebo dokonce
mene efektivni nez udalostmi rizeny kod. Zalezi na situaci. Nekdy je
eketivnejsi ten, jindy onen.

Dneska uz mnohem vic zalezi na logice programu. Nekdy logika programu
lepe sedi na blokujici cteni, jindy se zase lepe hodi na neblokuici
cteni. To je podle mne to nejdulezitejsi kriterium.

> Nema preto vyznam pouzivat ich aj tam, kde to nie je vyhodne.

Otocim to... jsou situace, kdy to naopak vyhodne je.  

> procedure TForm.ComPortRxChar(Sender: TObject);
> begin
> Spracuj(TComPort(Sender).ReadString);
> end;

krasny priklad... tim jsi demostroval co, jak je tvuj program jednoduchy?
Jak je asi jednoducha procedira 'spracuj'? A co dela asi ona metoda
ReadString? Neni tam nekde nahodou ukryte blokujici cteni, ze ne?  


--
Lukas Gebauer.

E-mail: gebauerl@mlp.cz
WEB: http://www.ararat.cz/synapse - Synapse Delphi and Kylix TCP/IP Library



Odpovedá: Erik Salaj, Winsoft

11. 8. 2004 16:20

> To je trosku jina pisnicka... kdyz nekdo napise seriovou komponenty,
> ktera je porad v principu udalostmi rizena, a pripise k tomu kod, kterym
> navic simuluje blokujici volani, tak je to porad pochopitelne o necem
> uplne jinem, nez kdyz se ti kod chova blokujicim zpusobem od uplneho
> zacatku. Hlavne prave z hlediska efektivity. Je to stejne, jako kdybych
> blokujici kody Synaseru obalil tak, aby volal udalosti. Jde to, ale
> nebude to nikdy tak efektivni jako kdyz bude kod psany od zacatku jako
> udalostmi rizeny.

nerozumiem o akom obalovani hovoris. Komponenty obaluju
maximalne tak Windows API. Nie je dovod nic simulovat,
postacuje vyuzit to, co Windows API pre seriovu komunikaciu
poskytuje a to tak udalosti ako aj timeouty. Neviem, ci som Ta
dobre pochopil, ale nie je potrebne generovat ani simulovat
ziadne udalosti, vsetko zabezpecuje Windows.

> Hardware vyvolava tak maximalne preruseni... ale to ovlada driver
> serioveho portu. Ten to vzdycky prechroustava, krmi do vlastnich
> internich bufferu, a az tento driver ridi komunikaci s aplikaci.
> Blokujici a neblokujici volani je ciste a jen o komunikaci s driverem a
> ne o komunikaci s hardwarem.

no vsimni si, ze hardware (UART) vyvolava prerusenia, na zaklade
ktorych potom Windows generuje eventy. Ale timeouty hardware
nepozna, to je uz cisto softwarova zalezitost (naprogramovana
v tom driveri).

> U udalostmi rizenem programovani serioveho portu dochazi k tomu, ze
> jakmile jsou nejaka data k dispozici, je volan tvuj program, aby si data
> precetl z bufferu a nejak zpracoval. Chci li precist treba souvisly
> kilobajt dat, bude muj program zavolan pravdepodobne hned nekolikrat, a
> moje obsluzna rutina si musi vsechna ta data pri kazdem volani nekam
> ulozit a zjistovat, jestli nahodou uz nejsou vsechna. V nejhorsim moznem
> pripade, kdy je udalost volana pro kazdy prijaty bajt dat zvlast
> (nastesti to se nestava...) se muj program docela namaka...

ano, to je optimalizovane tak, ze udalosti sa nevolaju pre kazdy
nacitany znak

> Zatimco blokujici zpusob udela to, ze zada pozadavek na prijmuti
> kilobajtu dat, a muj program se vesele uspi. Nic v tu chvili nedela,
> nezere vubec zadny strojovy cas... driver si sam do sebe vesele prijima
> data, a az jich ma mnou pozadovany kilobajt, tak muj program bude
> driverem probuzen, a je mi predan prave kolibajt dat. kdyz do urcite doby
> pozadovana data neprijou, je muj program probuzen s chybou.

no hej, program sa uspi, lenze ta seriovu komunikacia bezi dalej.
A musi sledovat timeouty (nejake casovace) a aktivovat uspaty program
v pripade, ked su data aj ked nie su data (chyby, atd.). To v pripade
pouzivania "len" udalosti nepotrebujes. Dalej to, ze program sa uspi
nie je vzdy vyhodne - uzivatel chce predsa vidiet, co sa deje, to by
sa mu asi nepacilo, keby mal cakat na kilobajty udajov a niekolko
sekundove timeouty.

> Nejak tu vic prace ohledne timeoutu nevidim, takze proc by to melo byt
> vice narocne? Ba naopak!

to, ze program spi, este neznamena, ze je komunikacia menej narocna  

> Takze nestras, ze by blokujici kod mel byt nejaky pomalejsi, nebo dokonce
> mene efektivni nez udalostmi rizeny kod. Zalezi na situaci. Nekdy je
> eketivnejsi ten, jindy onen.

pochybujem, ze timeouty mozu byt efektivnejsie, je tam vzdy
praca naviac (samozrejme drivera, nie tej spiacej aplikacie)
oproti eventom. Timeouty mozu byt vyhodnejsie z hladiska
programovania komunikacie, jednoduchsie pre programatora.
Niekedy.

> Dneska uz mnohem vic zalezi na logice programu. Nekdy logika programu
> lepe sedi na blokujici cteni, jindy se zase lepe hodi na neblokuici
> cteni. To je podle mne to nejdulezitejsi kriterium.

ano, to bude asi aj dovod, preco obidva tieto moznosti Windows poskytuje

> > procedure TForm.ComPortRxChar(Sender: TObject);
> > begin
> > Spracuj(TComPort(Sender).ReadString);
> > end;
>
> krasny priklad... tim jsi demostroval co, jak je tvuj program jednoduchy?
> Jak je asi jednoducha procedira 'spracuj'? A co dela asi ona metoda
> ReadString? Neni tam nekde nahodou ukryte blokujici cteni, ze ne?  

nie je tam ziadne blokujuce citanie. ReadString vrati tolko udajov
kolko je vo vstupnom bufferi, na nic necaka. Ak je povedzme buffer
prazdny ReadString vrati prazdny string. Skutocny kod v RxChar
je trocha zlozitejsi (asi 4 riadky), ale je to IMHO nepodstatne
(spracuj totiz testuje ukoncenie hexa kodu, cize moze spracovat
aj len cast prijatych udajov, zvysok sa odpameta a spracuje
pri dalsej RxChar udalosti spolu s novymi udajmi). Je to velmi
jednoduche a spolahlive riesenie, nic a nikoho neblokujuce.
Mam pocit, ze celkom nechapes ako to funguje, vzdy si tam
predstavujes nejake blokovanie - tak si napr. stiahni nas
komponent (http://www.winsoft.sk/comport.htm) alebo
nejaky iny a vyskusaj si to. Mame tam aj demopriklad
ktory udalost OnRxChar vyuziva.

Erik



Odpovedá: Lukas Gebauer

11. 8. 2004 18:56

> nerozumiem o akom obalovani hovoris. Komponenty obaluju
> maximalne tak Windows API. Nie je dovod nic simulovat,
> postacuje vyuzit to, co Windows API pre seriovu komunikaciu
> poskytuje a to tak udalosti ako aj timeouty. Neviem, ci som Ta
> dobre pochopil, ale nie je potrebne generovat ani simulovat
> ziadne udalosti, vsetko zabezpecuje Windows.

Zjevne nepochopil. Neslo o obalovani API. No nic.  

> no vsimni si, ze hardware (UART) vyvolava prerusenia, na zaklade
> ktorych potom Windows generuje eventy. Ale timeouty hardware
> nepozna, to je uz cisto softwarova zalezitost (naprogramovana
> v tom driveri).

A tim se mi snazis dokazat co? Vzdyt uplne ty stejne eventy pouziva i
blokujici zpusob prace! V pripade neblokujiciho pristupu ten driver musi
ten event dostat nejak do tve aplikace, coz neni vzdy nejrychlejsi...

> > U udalostmi rizenem programovani serioveho portu dochazi k tomu, ze
> > jakmile jsou nejaka data k dispozici, je volan tvuj program, aby si data
> > precetl z bufferu a nejak zpracoval. Chci li precist treba souvisly
> > kilobajt dat, bude muj program zavolan pravdepodobne hned nekolikrat, a
> > moje obsluzna rutina si musi vsechna ta data pri kazdem volani nekam
> > ulozit a zjistovat, jestli nahodou uz nejsou vsechna. V nejhorsim moznem
> > pripade, kdy je udalost volana pro kazdy prijaty bajt dat zvlast
> > (nastesti to se nestava...) se muj program docela namaka...
>
> ano, to je optimalizovane tak, ze udalosti sa nevolaju pre kazdy
> nacitany znak

Nicmene i tak se v klidu muze stat, ze je ten apliakcni event vyvolan
mnohokrate za jednu sekundyu, treba i stokrat za jednu sekundu. A stejne
tolikrat je volan veskery ten tvuj kod, ktery zpracovava nactena data.

> no hej, program sa uspi, lenze ta seriovu komunikacia bezi dalej.
> A musi sledovat timeouty (nejake casovace) a aktivovat uspaty program
> v pripade, ked su data aj ked nie su data (chyby, atd.). To v pripade
> pouzivania "len" udalosti nepotrebujes.

Snazis se mi namluvit, ze sledovani nejakeho casovace, ktery bezi na
urovni jadra operacniho systemu, bude stat vice nez posiklani nekolik
desitek messages za sekundu tvemu programu, a to uz nemluvim o tom tvem
kodu, ktery se musi pokazde vykonat? To myslis vazne?

Myslis vazne, ze probouzeni uspaneho programu v blokujicim rezimu stoji
vice casu nez uspaneho programu v neblokujicim rezimu? Co myslis ze tvuj
program dela, kdyz nema zrovna co na praci a ceka na nejakou tu udalost?
Ano, spi! a co se musi udelat, kdyz ta udalost prijde? Ano, musi se ten
program probudit!

Takze ja program jednou uspim a jednou probudim. Na pozadi pracuje driver
serioveho portu.

Ale v tvem pripade ten driver serioveho portu musi odvest UPLNE stejnou
praci, jen navic musi poslat minimalne nekolik eventu do aplikace, cimz
nekolikrat bude tva apliikace probuzena a uspana.

> Dalej to, ze program sa uspi nie je vzdy vyhodne - uzivatel chce predsa
> vidiet, co sa deje, to by sa mu asi nepacilo, keby mal cakat na
> kilobajty udajov a niekolko sekundove timeouty.

Thready, thready a jeste jednou thready. Ostatne, hlavni thread aplikace
je tu od toho, aby primarne obsluhoval uzivatelske rozhrani, a ne aby
pracoval se seriovym portem.

> pochybujem, ze timeouty mozu byt efektivnejsie, je tam vzdy
> praca naviac (samozrejme drivera, nie tej spiacej aplikacie)
> oproti eventom. Timeouty mozu byt vyhodnejsie z hladiska
> programovania komunikacie, jednoduchsie pre programatora.
> Niekedy.

Jenze ona tam vetsi prace driveru neni. To je tvuj blud.

> > krasny priklad... tim jsi demostroval co, jak je tvuj program jednoduchy?
> > Jak je asi jednoducha procedira 'spracuj'? A co dela asi ona metoda
> > ReadString? Neni tam nekde nahodou ukryte blokujici cteni, ze ne?  
> nie je tam ziadne blokujuce citanie. ReadString vrati tolko udajov
> kolko je vo vstupnom bufferi, na nic necaka.

... jen jsem se zeptal...  

> Mam pocit, ze celkom nechapes ako to funguje, vzdy si tam
> predstavujes nejake blokovanie - tak si napr. stiahni nas
> komponent (http://www.winsoft.sk/comport.htm) alebo
> nejaky iny a vyskusaj si to. Mame tam aj demopriklad
> ktory udalost OnRxChar vyuziva.

Ne, vubec netusim ktera bije.  


--
Lukas Gebauer.

E-mail: gebauerl@mlp.cz
WEB: http://www.ararat.cz/synapse - Synapse Delphi and Kylix TCP/IP Library



Odpovedá: Erik Salaj, Winsoft

11. 8. 2004 22:28

> > no vsimni si, ze hardware (UART) vyvolava prerusenia, na zaklade
> > ktorych potom Windows generuje eventy. Ale timeouty hardware
> > nepozna, to je uz cisto softwarova zalezitost (naprogramovana
> > v tom driveri).
>
> A tim se mi snazis dokazat co? Vzdyt uplne ty stejne eventy pouziva i
> blokujici zpusob prace! V pripade neblokujiciho pristupu ten driver musi
> ten event dostat nejak do tve aplikace, coz neni vzdy nejrychlejsi...

obvody seriovej komunikacie, ci sa Ti to paci alebo nie, funguju
na udalostiach (preruseniach) a preto tento sposob je a bude
zakladnym a efektivnym sposobom seriovej komunikacie tak
vo Windowse ako aj mimo Windowsu. K tomu sa potom
moze dorobit softwarova nadstavba na rozne ucely,
predovsetkym zjednodusenie programovania komunikacie.

Ze generovane eventy "zatazuju aplikaciu" - ano, ved od toho su,
aby moju aplikaciu informovali, ked pridu udaje alebo dojde k chybe.
Aj mys ked pohnem, tak sa generuju udalosti, ktore "zatazuju aplikaciu",
a to je akoze zle, ze ma informuju o pohybe mysi? To maju prist
len raz kazdu sekundu, aby "aplikaciu nezatazovali", alebo len vtedy
ked zavolam nejaku blokovaciu funkciu an mys? Myslim, ze Ti
unika alebo nechces vidiet vyznam udalosti. To je dost zvlastne
na programatora Windows aplikacii, ktore su kompletne
postavene na udalostami riadenom programovani.

Na porovnanie - problem timeoutov je ten, ze zbytocne zatazuju system
aj ked sa nekomunikuje (t.j. povedzme neprichadzaju udaje). Chcem
napriklad precitat dva bajty. Tak musim vymysliet nejaky timeout,
podla moznosti ani dlhy (aby som mohol monitorovat v rozumnom
case co sa deje) ani kratky (lebo bude zbytocne zatazovat system).
Aby aplikacia mohla nezavisle fungovat, tak k tomu este musim
dorobit thread a zabezpecit jeho synchronizaciu. Potom zavolam
blokovaciu funkciu, ze chcem precitat dva bajty. Zariadenie posle
hned jeden bajt a povedzme o hodinu druhy. Medzitym ma timeouty
povedzme raz za sekundu, cize spolu 3600 krat zbytocne informovali,
ze dva bajty este neprisli. A aj prvy bajt ziskam az o hodinu, ked pride
ten druhy bajt, hoci uz je davno prijaty (alebo ho pri timeoute mozem
precitat, niekde ulozit a pocitat si kolko zvysnych bajtov este treba
dalej citat?). A ak ten druhy bajt nepride do ukoncenia programu,
tak bud nedostanem ani ten precitany prvy bajt, alebo si ich musim
rucne skladat pocas timeoutov. V prvom pripade potom najlepsie
asi bude citat udaje vzdy po jednom bajte. Lenze ked budem citat
velke mnozstvo udajov, tak zase mam reziu volania funkcie citania
na kazdy bajt (eventov v tomto pripade dostane apliacia o dost menej).
V druhom pripade (skladania bajtov pocas timeoutov) sa straca efekt
jednoduchosti, ze zavolam si funkciu Precitaj100bajtov a nemusim
sa o nic starat. A pritom cely tento "naokolo blizsie" system
mozem elegantne vyriesit sledovanim udalosti prichodu znakov
a ich okamzitym spracovanim bez akychkolvek timeoutov,
threadov a dalsich vymyslanin. A dostanem v tomto pripade
dva eventy za hodinu ak mi za hodinu pridu dva bajty - zda sa
mi to teda vyhodne.

Na zaver doporucujem skusit uplne zrusit udalosti Windowsu,
ak su "zatazujuce" a urobit nadstavbu na blokovacie citanie
pohybu mysi, okien, atd. Pekne s timeoutami a threadmi.
Presvedcit sa prakticky ako to bude fungovat a ake je to
jednoduche, vyhodne a svizne  .

Erik


Odpovedá: Jan Novak

11. 8. 2004 23:11

> Takze nestras, ze by blokujici kod mel byt nejaky pomalejsi, nebo
> dokonce mene efektivni nez udalostmi rizeny kod.

Potreboval jsem kdysi overit, jak pocitac bude snaset, kdyz bude
komunikovat najednou 10 RS-232 plnou rychlosti in/out. Tak jsem si
udelal programek, kde tlacitkem spustim/stopnu souvisle vysilani
sekvence na libovolnem portu, checkboxem zapnu naslouchani s
kontrolou, zda prijaty byte je o 1 vetsi nez predchozi. Porty jsem
navzajem propojil kabliky. Pridavanim dalsich portu a zvysovanim
rychlosti se zvysovalo zatizeni CPU.

Stejny projekt jsem udelal s ASYNCFREE i SYNASER, bohuzel se mi
zachovala jen varianta ASYNCFREE, protoze ta druha uz nekde kolem
38kbit na 6 portech CPU totalne ucpala a nestihala prijimat, tak jsem
ji smazal.

Zajimave je, ze asyncfree varianta data prenasela bez chyby, i kdyz
refresh zobrazeni od timeru se uz nestihal volat.

Potreboval jsem tehdy rychle reagovat i na 1 prijaty byte, tak jsem
musel FiFo treshold in i out nastavit na 1 a opravdu se OnDataRecived
vyvolavala vetsinou po kazdem byte :-O a pekne to zatizilo CPU.
Bohuzel se po zmene fifo treshold musi restartovat windows. Neumite to
nekdo za jizdy?

Projekt (D4) vyzaduje instalovanou AsyncFree.
Soubor TestCom.rar je ulozen na adrese:
http://mail.volny.cz/fs/81babcecc870bf8d312283f01fa6efb1
Heslo ke stazeni: faunlu808

U propojovaciho kabelu program umozni overit krome RxD/TxD i propojeni
RTC/CTS a DTR/DSR.


Odpovedá: Erik Salaj, Winsoft

12. 8. 2004 12:00

> Potreboval jsem kdysi overit, jak pocitac bude snaset, kdyz bude
> komunikovat najednou 10 RS-232 plnou rychlosti in/out. Tak jsem si
> udelal programek, kde tlacitkem spustim/stopnu souvisle vysilani
> sekvence na libovolnem portu, checkboxem zapnu naslouchani s
> kontrolou, zda prijaty byte je o 1 vetsi nez predchozi. Porty jsem
> navzajem propojil kabliky. Pridavanim dalsich portu a zvysovanim
> rychlosti se zvysovalo zatizeni CPU.

sam som zvedavy ako pojde komunikacia u nasho zakaznika
so 64 COM portami. Data ale nebudeme citat z UARTov
ale zo 64 USB-Serial prevodnikov (virtualnych COM portov),
takze dufam, ze to pomocou USB utiahneme.

Erik


Odpovedá: Lukas Gebauer

12. 8. 2004 12:01

> Na zaver doporucujem skusit uplne zrusit udalosti Windowsu,
> ak su "zatazujuce" a urobit nadstavbu na blokovacie citanie
> pohybu mysi, okien, atd. Pekne s timeoutami a threadmi.
> Presvedcit sa prakticky ako to bude fungovat a ake je to
> jednoduche, vyhodne a svizne  .

Sklouzli jsme k tradicni demagogii, koncim diskuzi.


--
Lukas Gebauer.

E-mail: gebauerl@mlp.cz
http://www.ararat.cz/synapse/ - Ararat Synapse - TCP/IP Lib.


Odpovedá: Lukas Gebauer

12. 8. 2004 12:01

> Stejny projekt jsem udelal s ASYNCFREE i SYNASER, bohuzel se mi
> zachovala jen varianta ASYNCFREE, protoze ta druha uz nekde kolem
> 38kbit na 6 portech CPU totalne ucpala a nestihala prijimat, tak jsem
> ji smazal.

To je skoda ze nemas ten kod, protoze jsi tam musel mit neco
evidentne spatne. Bezne komunikuji na cca 400kilobitech (s virtualnim
seriakem na USB) a procesor o tom ani nevi, natoz aby se nekde neco
ucpavalo.



--
Lukas Gebauer.

E-mail: gebauerl@mlp.cz
http://www.ararat.cz/synapse/ - Ararat Synapse - TCP/IP Lib.


Odpovedá: Jan Novak

12. 8. 2004 12:01

>> nekde kolem 38kbit na 6 portech CPU totalne ucpala

> To je skoda ze nemas ten kod, protoze jsi tam musel
> mit neco evidentne spatne.

Neni problem upravit projekt tak, ze se na timer osahaji vsechny
aktivni porty a kdyz neco prislo, zavola se OnDataRecived. Problem je,
ze pri urcite zatezi uz se OnTimer prestava stihat volat, ale data se
sypou a sypou a asyncfree je jeste stiha kontrolovat. Synaseru se
casem preplni buffery a zacina ztracet bajty.

Jina moznost by byla mit pro prijem na kazdem portu svuj thread, to
jsem nezkousel.

Pochopitelne v praxi se takova situace nevyskytuje, vetsinou druha
strana ceka na nejake potvrzeni a ten sileny tok dat se zastavi, ale
testovaci programy jsou prave na to, aby overili mezni stavy.

> Bezne komunikuji na cca 400kilobitech (s virtualnim
> seriakem na USB) a procesor o tom ani nevi,
> natoz aby se nekde neco ucpavalo.

Halfduplex na jednom kanalu v pohode i s obycejnym (rychlym) UARTem.
Zkus full na osmi   na 400 Celeronu a s FiFo tresholdem=1. Jinak,
jaka je velikost FiFo u tech USB? To je vlastne jedno, u tohoto testu
se pri nestihacce jakykoliv buffer preplni za par sec.


Odpovedá: Lukas Gebauer

12. 8. 2004 12:01

> Neni problem upravit projekt tak, ze se na timer osahaji vsechny
> aktivni porty a kdyz neco prislo, zavola se OnDataRecived. Problem je,
> ze pri urcite zatezi uz se OnTimer prestava stihat volat, ale data se
> sypou a sypou a asyncfree je jeste stiha kontrolovat. Synaseru se
> casem preplni buffery a zacina ztracet bajty.

No to je prave typicke spatne pouziti Synaseru. Uvedom si, ze Synaser
a Asyncfree pouzivaji zcela odlisnou filozofii prace... nejde vzit
jednu filozofii a napcat ji na oboje.

Testovat pritomnost dat pomoci timeru je skutecne blbost, to nikdy
nemuze fungovat spravne. (uz jen pro to, ze doruceni udalosti timeru
neni z principu spolehlive... udalost timeru muze byt zcela legalne
systemem zahozena!)

> Jina moznost by byla mit pro prijem na kazdem portu svuj thread, to
> jsem nezkousel.

To kdybys skusil, nemel bys zadny problem!  



--
Lukas Gebauer.

E-mail: gebauerl@mlp.cz
http://www.ararat.cz/synapse/ - Ararat Synapse - TCP/IP Lib.


Odpovedá: Jiri Foldyna

12. 8. 2004 14:08

> obvody seriovej komunikacie, ci sa Ti to paci alebo nie, funguju
> na udalostiach (preruseniach) a preto tento sposob je a bude
> zakladnym a efektivnym sposobom seriovej komunikacie tak
> vo Windowse ako aj mimo Windowsu. K tomu sa potom
> moze dorobit softwarova nadstavba na rozne ucely,
> predovsetkym zjednodusenie programovania komunikacie.

Nesmysl, zalezi na konstrukci komunikacniho adapteru a reseni driveru. Ze se
to tak pouziva ve Windows, neznamena to automaticky, ze je to idealni.

> Ze generovane eventy "zatazuju aplikaciu" - ano, ved od toho su,
> aby moju aplikaciu informovali, ked pridu udaje alebo dojde k chybe.
> Aj mys ked pohnem, tak sa generuju udalosti, ktore "zatazuju
> aplikaciu",
> a to je akoze zle, ze ma informuju o pohybe mysi? To maju prist
> len raz kazdu sekundu, aby "aplikaciu nezatazovali", alebo len vtedy
> ked zavolam nejaku blokovaciu funkciu an mys? Myslim, ze Ti
> unika alebo nechces vidiet vyznam udalosti. To je dost zvlastne
> na programatora Windows aplikacii, ktore su kompletne
> postavene na udalostami riadenom programovani.

Nesmysl. Je rozdil, jestli mne implementace komunikaciho rozhrani nuti k
tomu, abych se staral o kazdy prijaty byte, nebo jestli mi umozni praci s
bloky. Samozrejme, u jednoduche konzolove aplikace to neocenis, u
protokolove orientovane komunikace je to velky prinos.

> Na porovnanie - problem timeoutov je ten, ze zbytocne zatazuju system
> aj ked sa nekomunikuje (t.j. povedzme neprichadzaju udaje). Chcem
> napriklad precitat dva bajty. Tak musim vymysliet nejaky timeout,
> podla moznosti ani dlhy (aby som mohol monitorovat v rozumnom
> case co sa deje) ani kratky (lebo bude zbytocne zatazovat system).
> Aby aplikacia mohla nezavisle fungovat, tak k tomu este musim
> dorobit thread a zabezpecit jeho synchronizaciu. Potom zavolam
> blokovaciu funkciu, ze chcem precitat dva bajty. Zariadenie posle
> hned jeden bajt a povedzme o hodinu druhy. Medzitym ma timeouty
> povedzme raz za sekundu, cize spolu 3600 krat zbytocne informovali,
> ze dva bajty este neprisli. A aj prvy bajt ziskam az o
> hodinu, ked pride
> ten druhy bajt, hoci uz je davno prijaty (alebo ho pri timeoute mozem
> precitat, niekde ulozit a pocitat si kolko zvysnych bajtov este treba
> dalej citat?). A ak ten druhy bajt nepride do ukoncenia programu,
> tak bud nedostanem ani ten precitany prvy bajt, alebo si ich musim
> rucne skladat pocas timeoutov. V prvom pripade potom najlepsie
> asi bude citat udaje vzdy po jednom bajte. Lenze ked budem citat
> velke mnozstvo udajov, tak zase mam reziu volania funkcie citania
> na kazdy bajt (eventov v tomto pripade dostane apliacia o dost menej).
> V druhom pripade (skladania bajtov pocas timeoutov) sa straca efekt
> jednoduchosti, ze zavolam si funkciu Precitaj100bajtov a nemusim
> sa o nic starat. A pritom cely tento "naokolo blizsie" system
> mozem elegantne vyriesit sledovanim udalosti prichodu znakov
> a ich okamzitym spracovanim bez akychkolvek timeoutov,
> threadov a dalsich vymyslanin. A dostanem v tomto pripade
> dva eventy za hodinu ak mi za hodinu pridu dva bajty - zda sa
> mi to teda vyhodne.

Nesmysl. Komunikace po seriove lince bez timeoutu (at na urovni driveru ci
aplikace) je pouzitelna maximalne pro demonstracni ucely, nebo pro realizaci
velmi jednoduche konzoly. Cokoli co pouzije nejaky protokol, potrebuje taky
timeouty. Pokud je nezajisti driver, musi je realizovat aplikace.

> Na zaver doporucujem skusit uplne zrusit udalosti Windowsu,
> ak su "zatazujuce" a urobit nadstavbu na blokovacie citanie
> pohybu mysi, okien, atd. Pekne s timeoutami a threadmi.
> Presvedcit sa prakticky ako to bude fungovat a ake je to
> jednoduche, vyhodne a svizne  .

Tomu nerozumim, to je pokus o ironicky zert ????

> Erik


Zdravim

Jiri Foldyna



Odpovedá: Tomas Bradle

12. 8. 2004 14:18

Muzu se zeptat, jak k tomu muze dojit ?

diky

Tomas Bradle
t.bradle@worldonline.cz


----- Original Message -----
From: "Lukas Gebauer" <gebylist@mlp.cz>
To: <delphi-l@clexpert.cz>
Sent: Thursday, August 12, 2004 10:13 AM
Subject: Re: Synaser a prace s nim


> neni z principu spolehlive... udalost timeru muze byt zcela legalne
> systemem zahozena!)
>
> Lukas Gebauer.



Odpovedá: Tomas Bradle

12. 8. 2004 14:30

TBlockSerial lze primo v kodu threadu pouzivat bez nejake dalsi
synchronizace ?

diky

Tomas Bradle
t.bradle@worldonline.cz


----- Original Message -----
From: "Lukas Gebauer" <gebylist@mlp.cz>
To: <delphi-l@clexpert.cz>
Sent: Thursday, August 12, 2004 10:13 AM
Subject: Re: Synaser a prace s nim


> > Jina moznost by byla mit pro prijem na kazdem portu svuj thread, to
> > jsem nezkousel.
>
> To kdybys skusil, nemel bys zadny problem!  
>
>
> --
> Lukas Gebauer.



Odpovedá: Erik Salaj, Winsoft

12. 8. 2004 14:44

> > obvody seriovej komunikacie, ci sa Ti to paci alebo nie, funguju
> > na udalostiach (preruseniach) a preto tento sposob je a bude
> > zakladnym a efektivnym sposobom seriovej komunikacie tak
> > vo Windowse ako aj mimo Windowsu. K tomu sa potom
> > moze dorobit softwarova nadstavba na rozne ucely,
> > predovsetkym zjednodusenie programovania komunikacie.
>
> Nesmysl, zalezi na konstrukci komunikacniho adapteru a reseni driveru. Ze
se
> to tak pouziva ve Windows, neznamena to automaticky, ze je to idealni.

skus si radsej najprv nastudovat tie obvody (UARTY) pouzivane
v PC-ckach na seriovu komunikaciu. Obavam sa, ze ten hardware
funguje rovnako a programuje sa rovnako vo Windowse aj v Linuxe
aj v hocicom inom. Ci to je "idealni" to mozes asi skor diskutovat
s vyrobcami tychto obvodov a pripadne vymysliet lepsie.

> Nesmysl. Je rozdil, jestli mne implementace komunikaciho rozhrani nuti k
> tomu, abych se staral o kazdy prijaty byte, nebo jestli mi umozni praci s
> bloky. Samozrejme, u jednoduche konzolove aplikace to neocenis, u
> protokolove orientovane komunikace je to velky prinos.

 

> Nesmysl. Komunikace po seriove lince bez timeoutu (at na urovni driveru ci
> aplikace) je pouzitelna maximalne pro demonstracni ucely, nebo pro
realizaci
> velmi jednoduche konzoly. Cokoli co pouzije nejaky protokol, potrebuje
taky
> timeouty. Pokud je nezajisti driver, musi je realizovat aplikace.

no vidis, a ja taku komunikaciu vyuzivam v programoch, ked
je to vyhodne. A aj ine podobne komponenty (dokonca i od firiem
ako je MS) to takto umoznuju vyuzivat. Ze kazdy protokol potrebuje
timeouty - s takymito zjavnymi blbostami sa mozes (nielen) tu
maximalne ak zosmiesnit.

> > Na zaver doporucujem skusit uplne zrusit udalosti Windowsu,
> > ak su "zatazujuce" a urobit nadstavbu na blokovacie citanie
> > pohybu mysi, okien, atd. Pekne s timeoutami a threadmi.
> > Presvedcit sa prakticky ako to bude fungovat a ake je to
> > jednoduche, vyhodne a svizne  .
>
> Tomu nerozumim, to je pokus o ironicky zert ????

to je navrh pre tych, co si myslia, ze udalosti nie su vhodne
na komunikaciu, nech vyskusaju komunikaciu bez nich.

Mozno by si mohol ten moj jednoriadkovy program
na citanie dat pomocou udalosti prerobit na timeouty
a ukazat nazorne vyhody tych timeoutov na tomto
konkretnom priklade.

Erik



Odpovedá: Lukas Gebauer

12. 8. 2004 14:41

> TBlockSerial lze primo v kodu threadu pouzivat bez nejake dalsi
> synchronizace ?

Proc by TBlockSerial potreboval nejakou synchropnizaci? ty potrebuje
maximalne tvuj kod okolo, aby sdelil hlavnimu thredu vysledek
operace, nebo tak nejak.

Synaser je jinak ve svem vlastnim threadu plne spokojeny.


--
Lukas Gebauer.

E-mail: gebauerl@mlp.cz
http://www.ararat.cz/synapse/ - Ararat Synapse - TCP/IP Lib.


Odpovedá: Lukas Gebauer

12. 8. 2004 15:00

> Mozno by si mohol ten moj jednoriadkovy program
> na citanie dat pomocou udalosti prerobit na timeouty
> a ukazat nazorne vyhody tych timeoutov na tomto
> konkretnom priklade.

Ty jsi fakt neskutecny... nevim jak ostatni, ale JA jsem tu zadny
tvuj JEDNORADKOVY program opravdu, ale opravdu nevidel!

Poslal si sem sice jeden radek kodu, ale ten volal tvoji proceduru
'spracuj'. To umi kazdy jakykoliv kod zabalit do procedury, pak sem
dat v jednom radku volani te procedury a ohanet se tim, ze je to
jednoradkove reseni. Neni, jen kalis vodu...


--
Lukas Gebauer.

E-mail: gebauerl@mlp.cz
http://www.ararat.cz/synapse/ - Ararat Synapse - TCP/IP Lib.


Odpovedá: Jiri Foldyna

12. 8. 2004 15:24

> skus si radsej najprv nastudovat tie obvody (UARTY) pouzivane
> v PC-ckach na seriovu komunikaciu. Obavam sa, ze ten hardware
> funguje rovnako a programuje sa rovnako vo Windowse aj v Linuxe
> aj v hocicom inom. Ci to je "idealni" to mozes asi skor diskutovat
> s vyrobcami tychto obvodov a pripadne vymysliet lepsie.

Neni potreba, mam to davno za sebou. S UARTy (a USARTy) jsem pracoval uz v
dobe, kdy se IBM PC teprve rodilo.

> no vidis, a ja taku komunikaciu vyuzivam v programoch, ked
> je to vyhodne. A aj ine podobne komponenty (dokonca i od firiem
> ako je MS) to takto umoznuju vyuzivat. Ze kazdy protokol potrebuje
> timeouty - s takymito zjavnymi blbostami sa mozes (nielen) tu
> maximalne ak zosmiesnit.

Smesna je domnenka, ze protokol nepotrebuje timeout. Duvod je evidentni,
zkus premyslet, nez neco napises.

> to je navrh pre tych, co si myslia, ze udalosti nie su vhodne
> na komunikaciu, nech vyskusaju komunikaciu bez nich.

Nikdo netvrdi, ze komunikaci nelze resit pomoci udalosti.

> Mozno by si mohol ten moj jednoriadkovy program
> na citanie dat pomocou udalosti prerobit na timeouty
> a ukazat nazorne vyhody tych timeoutov na tomto
> konkretnom priklade.

Mozna bys mohl zkusit predvest realizaci jednoducheho protokolu bez timeoutu
pouze pomoci udalosti  

Zkus toto:

Master = PC, 16 slave zarizeni pripojenych treba po RS-485.

Master zahaji komunikaci odeslanim 5A, 00 az 0F a ceka na ACK (00 az 0F, A5)
Pokud do 2 sec ACK neobdrzi, zaloguje se chyba a adresuje se dalsi slave.
Pokud ACK obdrzi, ceka 5 sec na prijeti 32 byte zpravy. Pokud zprava
neprijde, zaloguje se chyba.

Zdravim

Jiri Foldyna


Odpovedá: Erik Salaj, Winsoft

12. 8. 2004 15:15

> Ty jsi fakt neskutecny... nevim jak ostatni, ale JA jsem tu zadny
> tvuj JEDNORADKOVY program opravdu, ale opravdu nevidel!
>
> Poslal si sem sice jeden radek kodu, ale ten volal tvoji proceduru
> 'spracuj'. To umi kazdy jakykoliv kod zabalit do procedury, pak sem
> dat v jednom radku volani te procedury a ohanet se tim, ze je to
> jednoradkove reseni. Neni, jen kalis vodu...

ale ved ide o tu komunikaciu a nie o spracovanie udajov.
To je uz uplne jedno co Spracuj s prijatymi udajmi urobi.
Ak nevies takto abstrakne mysliet, tak si namiesto
Spracuj napis Write (do suboru). A ten subor potom
este treba niekde otvorit a zatvorit - to si uz niekde
dufam nastudujes, ze ako. Alebo mam naozaj poslat
kompletny program?

Erik


Odpovedá: Lukas Gebauer

12. 8. 2004 15:34

Inu, protoze (citace z MSDN):

"The WM_TIMER message is a low-priority message. The GetMessage and
PeekMessage functions post this message only when no other higher-
priority messages are in the thread's message queue."

Tedy, wm_timer udalost je vesele predbihana vsemi ostatnimi
udalostmi... a tak logicky, k udalosti timeru nemusi vubec dojit.

> Muzu se zeptat, jak k tomu muze dojit ?
>
> > neni z principu spolehlive... udalost timeru muze byt zcela legalne
> > systemem zahozena!)


--
Lukas Gebauer.

E-mail: gebauerl@mlp.cz
http://www.ararat.cz/synapse/ - Ararat Synapse - TCP/IP Lib.


Odpovedá: delphin@post.cz

12. 8. 2004 15:08

> obvody seriovej komunikacie, ci sa Ti to paci alebo nie, funguju
> na udalostiach (preruseniach) a preto tento sposob je a bude
> zakladnym a efektivnym sposobom seriovej komunikacie tak
> vo Windowse ako aj mimo Windowsu. K tomu sa potom
> moze dorobit softwarova nadstavba na rozne ucely,
> predovsetkym zjednodusenie programovania komunikacie.

Pri 115200 baudech a zapnute vstupni FIFO se vyvola preruseni a nasledne
udalost cca 1000x za sekundu. Na aplikacni urovni to neni sance spolehlivne
zvladnout.


Odpovedá: Lukas Gebauer

12. 8. 2004 15:16

> ale ved ide o tu komunikaciu a nie o spracovanie udajov.
> To je uz uplne jedno co Spracuj s prijatymi udajmi urobi.

Pro tebe zjevne ne, ale pro vsechny ostatni je komunikace nejen o
nejakem nesourodem proudu dat, ale hlavne take o porozumneni a
implementaci komunikacniho protokolu.

> Ak nevies takto abstrakne mysliet, tak si namiesto
> Spracuj napis Write (do suboru). A ten subor potom

Jestli predvadis vzor abstraktniho mysleni, pak uz rozumim tomu, proc
nechapu moderni abstraktni umeni a proc se radeji podivam na nejakou
klasiku.  


--
Lukas Gebauer.

E-mail: gebauerl@mlp.cz
http://www.ararat.cz/synapse/ - Ararat Synapse - TCP/IP Lib.


Odpovedá: Erik Salaj, Winsoft

12. 8. 2004 15:32

> Pri 115200 baudech a zapnute vstupni FIFO se vyvola preruseni a nasledne
> udalost cca 1000x za sekundu. Na aplikacni urovni to neni sance
spolehlivne
> zvladnout.

od toho je tam ten driver, aby to zvladol. Ved aplikacia nemusi dostat
1000 eventov za sekundu. Aj mysou ked pohnes, tak aplikacia nedostane
tisic eventov generovanych od mysi.

Erik


Odpovedá: Erik Salaj, Winsoft

12. 8. 2004 15:43

> > no vidis, a ja taku komunikaciu vyuzivam v programoch, ked
> > je to vyhodne. A aj ine podobne komponenty (dokonca i od firiem
> > ako je MS) to takto umoznuju vyuzivat. Ze kazdy protokol potrebuje
> > timeouty - s takymito zjavnymi blbostami sa mozes (nielen) tu
> > maximalne ak zosmiesnit.
>
> Smesna je domnenka, ze protokol nepotrebuje timeout. Duvod je evidentni,
> zkus premyslet, nez neco napises.

no vidis a ja som vcera poslal zakaznikovi program, ktory komunikuje
a ziadne timeouty nepotrebuje

> Mozna bys mohl zkusit predvest realizaci jednoducheho protokolu bez
timeoutu
> pouze pomoci udalosti  
>
> Zkus toto:
>
> Master = PC, 16 slave zarizeni pripojenych treba po RS-485.
>
> Master zahaji komunikaci odeslanim 5A, 00 az 0F a ceka na ACK (00 az 0F,
A5)
> Pokud do 2 sec ACK neobdrzi, zaloguje se chyba a adresuje se dalsi slave.
> Pokud ACK obdrzi, ceka 5 sec na prijeti 32 byte zpravy. Pokud zprava
> neprijde, zaloguje se chyba.

zase sme na zaciatku - jasne som napisal, tu to este raz citujem:

"vecsina komponentov AIK umoznuje pouzivat tak udalosti ako aj cakanie
s timeoutom. Obidva tieto moznosti maju svoje vyhody aj nevyhody
a obidva su podporovane Windowsom"

ze niekedy su timeouty vyhodne a niekedy nie. Niektori experti sa ma
ale snazia presvedcit, ze ich "alternativa" len s timeoutami (bez udalosti)
je lepsia. Alebo dokonca, ze timeouty su nevyhnutne pre komunikaciu.

V Tvojom konkretnom pripade komunikacie, ktoru si popisal SU timeouty
vyhodne, lebo ved pomocou nich je ten protokol definovany. Ale su
aj ine protokoly, kde timeouty vyhodne nie su. A uviedol som priklad
jednej mojej aplikacie, ktoru som takto bez timeoutov riesil (a
"jednoduchsie
riesenie" tejto aplikacie s timeoutami zatial akosi nikto
neposlal na
porovnanie).

Takze je IMHO dobre mat a pouzivat TAK UDALOSTI AKO AJ TIMEOUTY
podla konkretnych podmienok.

Erik


Odpovedá: Tomas Bradle

12. 8. 2004 16:13

No jasne, s tim jsem se uz setkal, doslo k takovemu zahlceni programu, ze
WM_TIMER dobehla az kdyz doslo k odlehceni procesoru, muze se ale WM_TIMER
uplne ztratit ? Kdyz mi nevadi, ze dorazi treba za 20s, ale potrebuji aby
dorazila.

diky

Tomas Bradle
t.bradle@worldonline.cz


----- Original Message -----
From: "Lukas Gebauer" <gebylist@mlp.cz>
To: <delphi-l@clexpert.cz>
Sent: Thursday, August 12, 2004 3:56 PM
Subject: Re: Synaser a prace s nim


> Inu, protoze (citace z MSDN):
>
>
"The WM_TIMER message is a low-priority message. The GetMessage and
> PeekMessage functions post this message only when no other higher-
> priority messages are in the thread's message queue."
>
> Tedy, wm_timer udalost je vesele predbihana vsemi ostatnimi
> udalostmi... a tak logicky, k udalosti timeru nemusi vubec dojit.
>
> Lukas Gebauer.



Odpovedá: Lukas Gebauer

12. 8. 2004 16:19

> No jasne, s tim jsem se uz setkal, doslo k takovemu zahlceni programu,
> ze WM_TIMER dobehla az kdyz doslo k odlehceni procesoru, muze se ale
> WM_TIMER uplne ztratit ? Kdyz mi nevadi, ze dorazi treba za 20s, ale
> potrebuji aby dorazila.

Nevim to na 100% (musim se doma podivat do chytre knizky), ale mam
pocit, ze za urcitych okolnosti neni tato zprava vubec zarazena do
fronty zprav. Snad si doma vzpomenu a najdu to presne. mozna se
mylim...

Nicmene co mne ted napada, tak klidne muze dojit k situaci, kdy ta
zprava zpracovana nebude, protoze prijde zprava o ukonceni programu.
V takovem pripade ta WM_time nebude zpracovana, i kdyz vznikla davno
pred tim, nez vubec vzniknul pozadavek na ukonceni programu, ktery ji
jednoduse predbehl, ne?



--
Lukas Gebauer.

E-mail: gebauerl@mlp.cz
http://www.ararat.cz/synapse/ - Ararat Synapse - TCP/IP Lib.


Odpovedá: Tomas Bradle

12. 8. 2004 16:31

No to by nevadilo v pripade, ze ta zprava je dulezita jen pro chod aplikace.
Neni aplikace - tudiz nepotrebuje zpravu.

Tomas Bradle
t.bradle@worldonline.cz


----- Original Message -----
From: "Lukas Gebauer" <gebylist@mlp.cz>
To: <delphi-l@clexpert.cz>
Sent: Thursday, August 12, 2004 5:18 PM
Subject: Re: Synaser a prace s nim


> > No jasne, s tim jsem se uz setkal, doslo k takovemu zahlceni programu,
> > ze WM_TIMER dobehla az kdyz doslo k odlehceni procesoru, muze se ale
> > WM_TIMER uplne ztratit ? Kdyz mi nevadi, ze dorazi treba za 20s, ale
> > potrebuji aby dorazila.
>
> Nevim to na 100% (musim se doma podivat do chytre knizky), ale mam
> pocit, ze za urcitych okolnosti neni tato zprava vubec zarazena do
> fronty zprav. Snad si doma vzpomenu a najdu to presne. mozna se
> mylim...
>
> Nicmene co mne ted napada, tak klidne muze dojit k situaci, kdy ta
> zprava zpracovana nebude, protoze prijde zprava o ukonceni programu.
> V takovem pripade ta WM_time nebude zpracovana, i kdyz vznikla davno
> pred tim, nez vubec vzniknul pozadavek na ukonceni programu, ktery ji
> jednoduse predbehl, ne?
>
>
> --
> Lukas Gebauer.



Odpovedá: Petr Zahradnik

12. 8. 2004 17:31

Puvodni zprava ze dne 12.8.2004:

> Pro tebe zjevne ne, ale pro vsechny ostatni je komunikace nejen o
> nejakem nesourodem proudu dat, ale hlavne take o porozumneni a
> implementaci komunikacniho protokolu.

Lukasi, kdyz tu posledni dva dny tak sleduji, co pises, tak se pomalu
prestavam divit tomu, proc pouzivas ty klavesnicove ctecky caroveho
kodu namisto seriovych.

Jinak jen kratkou poznamku - opravdu, ale opravdu nechapu, proc se
nekdo snazi asynchronni komunikaci (ktera je logicky asynchronni
pocinaje uz svou podstatou, pres vlastni komunikacni obvod, driver, az
do windows) synchronizovat ci spise serializovat na urovni aplikace.
To se tyka jak komunikace seriove RS-232, tak i treba internetu TCP/IP
apod.

Tyto komunikacni kanaly jsou asynchronni a stale budou asynchronni,
jediny mozny duvod, proc to delat, je snad kvuli UB programatorum,
kteri si sice v aplikaci hraji na udalosti, protoze Delphi je plne
udalosti, coz je zcela logicke, ale pak tam vrznou neco podobneho.
Takovi UB programatori vetsinou neumeji thready, takze to pak vypada,
jak to vypada.

Obslouzeni asynchronni komunikace je malinko obtiznejsi nez kdyz cekam
na 10 znaku (a UB programator ceka, dokud nekdo nevypne proud), ale to
podle me neni duvod...

Petr Zahradnik, pocitacovy expert

==========================================================
Petr Zahradnik, Computer Laboratory
Obvodova 740/14, 400 07 Usti nad Labem
telefon: 475 501 627, mobil: 602 409 601, fax: 475 511 338
web: http://www.clexpert.cz, e-mail: clexpert@clexpert.cz
ICQ: 21215917, MSN: clexpert@clexpert.cz
==========================================================


Odpovedá: Petr Zahradnik

12. 8. 2004 17:25

Puvodni zprava ze dne 12.8.2004:

> Pri 115200 baudech a zapnute vstupni FIFO se vyvola preruseni a
> nasledne udalost cca 1000x za sekundu. Na aplikacni urovni to neni
> sance spolehlivne zvladnout.

Misto podobnych vypoctu bych spise doporucil nejakou literaturu, kde
by ses dozvedel, jak to doopravdy funguje.

Petr Zahradnik, pocitacovy expert

==========================================================
Petr Zahradnik, Computer Laboratory
Obvodova 740/14, 400 07 Usti nad Labem
telefon: 475 501 627, mobil: 602 409 601, fax: 475 511 338
web: http://www.clexpert.cz, e-mail: clexpert@clexpert.cz
ICQ: 21215917, MSN: clexpert@clexpert.cz
==========================================================



Odpovedá: delphin@post.cz

12. 8. 2004 17:59

> > Pri 115200 baudech a zapnute vstupni FIFO se vyvola preruseni a
> > nasledne udalost cca 1000x za sekundu. Na aplikacni urovni to neni
> > sance spolehlivne zvladnout.
>
> Misto podobnych vypoctu bych spise doporucil nejakou literaturu, kde
> by ses dozvedel, jak to doopravdy funguje.

Zapomel jsem napsat, ze se jedna o maximalni hodnotu. Pochopitelne kdyz
nechodi data, nedeje se nic.


Odpovedá: Lukas Gebauer

12. 8. 2004 20:07

> No to by nevadilo v pripade, ze ta zprava je dulezita jen pro chod aplikace.
> Neni aplikace - tudiz nepotrebuje zpravu.

Jiste, to je pravda.

To dulezite, co jsem chtel sdelit, je, ze pouzivat timer na to, abych v
pravidel;nych intervalech cetl data z nejakeho zarizeni, neni dpobry
napad, protoze udalosti timeru maji nejnizsi prioritu, a tak muze byt do
apliace durocovan znacne nepravidlene.

A to prave zpusobovalo ony problemy s pretecenim bufferu ve zminovane
testovaci aplikaci. Ve spatne naprogramovanem testu nemohl Synaser
fungovat dobre.


--
Lukas Gebauer.

E-mail: gebauerl@mlp.cz
WEB: http://www.ararat.cz/synapse - Synapse Delphi and Kylix TCP/IP Library



Odpovedá: Lukas Gebauer

12. 8. 2004 20:17

> Jinak jen kratkou poznamku - opravdu, ale opravdu nechapu, proc se
> nekdo snazi asynchronni komunikaci (ktera je logicky asynchronni
> pocinaje uz svou podstatou, pres vlastni komunikacni obvod, driver, az
> do windows) synchronizovat ci spise serializovat na urovni aplikace.
> To se tyka jak komunikace seriove RS-232, tak i treba internetu TCP/IP
> apod.

No, modri uz vedi, ze mnoho komunikacncih protokolu, zvlaste tech
internetovych, jsou totiz z podstaty synchronni. (mluvim o komunikacnich
protokolech, ne o tom jak si UARTy tahaji za dratky...) Tak odtud asi
prameni ta vule to synchronizovat. A ver, ze to opravdu mnoho lidi
povazuje za sikovne. Jiste, nemuze se to zavdecit vsem a vzdy.

Ale podobna debata to uz kdysi byla, a nehodlam ji opakovat, protoze fakt
nikam nevedla.  



--
Lukas Gebauer.

E-mail: gebauerl@mlp.cz
WEB: http://www.ararat.cz/synapse - Synapse Delphi and Kylix TCP/IP Library



Odpovedá: Jiri Foldyna

12. 8. 2004 22:20

> Lukasi, kdyz tu posledni dva dny tak sleduji, co pises, tak se pomalu
> prestavam divit tomu, proc pouzivas ty klavesnicove ctecky caroveho
> kodu namisto seriovych.
>
> Jinak jen kratkou poznamku - opravdu, ale opravdu nechapu, proc se
> nekdo snazi asynchronni komunikaci (ktera je logicky asynchronni
> pocinaje uz svou podstatou, pres vlastni komunikacni obvod, driver, az
> do windows) synchronizovat ci spise serializovat na urovni aplikace.
> To se tyka jak komunikace seriove RS-232, tak i treba internetu TCP/IP
> apod.
>
> Tyto komunikacni kanaly jsou asynchronni a stale budou asynchronni,
> jediny mozny duvod, proc to delat, je snad kvuli UB programatorum,
> kteri si sice v aplikaci hraji na udalosti, protoze Delphi je plne
> udalosti, coz je zcela logicke, ale pak tam vrznou neco podobneho.
> Takovi UB programatori vetsinou neumeji thready, takze to pak vypada,
> jak to vypada.
>
> Obslouzeni asynchronni komunikace je malinko obtiznejsi nez kdyz cekam
> na 10 znaku (a UB programator ceka, dokud nekdo nevypne proud), ale to
> podle me neni duvod...

Asi takto - kazdy, kdo nekdy resil problem provozu 7x24 s error recovery bez
zasahu obsluhy, vi, ze se bez synchronizace komunikace neobejde. Proste
komunikacni session v techto pripadech zacit muze v podstate kdykoli, ale
skoncit MUSI podle definovanych pravidel. Prakticky vzdy se pouziva detekce
chyb nedodrzenim casovani protokolu, uz proto, ze nedodrzeni casovani
signalizuje bud chybu v algoritmu nebo nepredpokladany stav systemu, coz je
u solidne resenych systemu s vysokou pozadovanou spolehlivosti vzdy duvod ke
zvyseni ostrazitosti. Tyto technologie (synchronizace komunikace) nejsou
nijak zvlast obtizne implementovatelne, pouze vyzaduji schopnost
abstraktniho a paralelniho uvazovani pri analyze a navrhu systemu. To muze
byt pro mene kvalifikovane analytiky problem, avsak nepochopeni problemu a
metodiky reseni jeste nediskvalifikuje metodu. Spousta lidi (i v teto
konferenci) uvazuje pouze v dimenzich klikaciho sestavovani jakz takz
fungujicich programu. Lukas je jeden z mala, kteri chapou, ze udalost
startuje nejaky proces, tedy ze neni entitou sama o sobe, a ze jeji obsluha
(lhostejno zda na urovni driveru, wrapperu API funkce nebo eventu v
aplikaci) NEPOSTACUJE ke kompletnimu reseni komunikacni ulohy. Proto
povazuji SYNASER za prinosny pristup k reseni komunikace pomoci RS-232 na PC
uz tim, ze se snazi do svych funkci zabalit krome proste obsluhy udalosti i
navazne cinnosti, nezbytne ke spolehlivemu reseni komunikace. To je alespon
meho pohledu (mozna deformovaneho lety prace v oblasti ridicich a mericich
systemu) velmi cenne.

Zdravim

Jiri Foldyna


Odpovedá: Erik Salaj, Winsoft

12. 8. 2004 23:01

> zvyseni ostrazitosti. Tyto technologie (synchronizace komunikace) nejsou
> nijak zvlast obtizne implementovatelne, pouze vyzaduji schopnost
> abstraktniho a paralelniho uvazovani pri analyze a navrhu systemu. To muze
> byt pro mene kvalifikovane analytiky problem, avsak nepochopeni problemu a
> metodiky reseni jeste nediskvalifikuje metodu. Spousta lidi (i v teto
> konferenci) uvazuje pouze v dimenzich klikaciho sestavovani jakz takz

ak tym "klikacim sestavovanim" myslis programovanie udalosti,
tak (nielen) vo Windowsoch to odjakziva tak fungovalo a funguje
(vitaj vo svete udalostami riadeneho programovania).

Mozno namiesto vzletnych reci o kvalifikovanych analytikoch, by
si tu mohol popisat lepsi system, kde je to robene inac, teda lepsie
(ze by MS DOS? ale aj tam som si programoval seriovu komunikaciu
s preruseniami ;-( ). Rad sa poucim. Ja uz som tu sam navrhoval urobit
ovladanie mysi timeoutami pre tych, co su na udalosti alergicki ale nejak
sa tu zatial nestretlo s priaznivou odozvou.

> fungujicich programu. Lukas je jeden z mala, kteri chapou, ze udalost
> startuje nejaky proces, tedy ze neni entitou sama o sobe, a ze jeji
obsluha
> (lhostejno zda na urovni driveru, wrapperu API funkce nebo eventu v
> aplikaci) NEPOSTACUJE ke kompletnimu reseni komunikacni ulohy. Proto

mojej mysi to nastastie uplne POSTACUJE

> povazuji SYNASER za prinosny pristup k reseni komunikace pomoci RS-232 na
PC
> uz tim, ze se snazi do svych funkci zabalit krome proste obsluhy udalosti
i
> navazne cinnosti, nezbytne ke spolehlivemu reseni komunikace. To je
alespon
> meho pohledu (mozna deformovaneho lety prace v oblasti ridicich a mericich
> systemu) velmi cenne.

tak navrhujem "zabalit" aj eventy vsetkych Delphi komponentov,
ked uz tu mame to nove, spolahlive riesenie komunikacie

Erik


Odpovedá: Petr Zahradnik

12. 8. 2004 23:17

Puvodni zprava ze dne 12.8.2004:

> Asi takto - kazdy, kdo nekdy resil problem provozu 7x24 s error
> recovery bez zasahu obsluhy, vi, ze se bez synchronizace komunikace
> neobejde. Proste komunikacni session v techto pripadech zacit muze v
> podstate kdykoli, ale skoncit MUSI podle definovanych pravidel.

Ja jsem asi natvrdlej. Ja porad nechapu, kde je problem toto resit
pomoci nedoprasene asynchronni komunikace, ktera vyvolava udalosti.

> Prakticky vzdy se pouziva detekce chyb nedodrzenim casovani
> protokolu, uz proto, ze nedodrzeni casovani signalizuje bud chybu v
> algoritmu nebo nepredpokladany stav systemu, coz je u solidne
> resenych systemu s vysokou pozadovanou spolehlivosti vzdy duvod ke
> zvyseni ostrazitosti. Tyto technologie (synchronizace komunikace)
> nejsou nijak zvlast obtizne implementovatelne, pouze vyzaduji
> schopnost abstraktniho a paralelniho uvazovani pri analyze a navrhu
> systemu. To muze byt pro mene kvalifikovane analytiky problem, avsak
> nepochopeni problemu a metodiky reseni jeste nediskvalifikuje
> metodu.

Stale jsem asi natvrdlej - takze jako chces tim rict, ze kdyz je nekdo
tak tupej, ze neumi obslouzit udalost, ale zato umi zavolat metodu a
cekat, jestli proces z ni vyleze nebo nevyleze, tak ma delat aplikace
pro provoz 24x7? Pekne dekuji.

> Spousta lidi (i v teto konferenci) uvazuje pouze v dimenzich
> klikaciho sestavovani jakz takz fungujicich programu.

Tak ti jako maji delat ty aplikace 24x7? Nebo co jsi tim chtel rici?

> Lukas je jeden z mala, kteri chapou, ze udalost startuje nejaky
> proces, tedy ze neni entitou sama o sobe, a ze jeji obsluha
> (lhostejno zda na urovni driveru, wrapperu API funkce nebo eventu v
> aplikaci) NEPOSTACUJE ke kompletnimu reseni komunikacni ulohy. Proto
> povazuji SYNASER za prinosny pristup k reseni komunikace pomoci
> RS-232 na PC uz tim, ze se snazi do svych funkci zabalit krome
> proste obsluhy udalosti i navazne cinnosti, nezbytne ke spolehlivemu
> reseni komunikace. To je alespon meho pohledu (mozna deformovaneho
> lety prace v oblasti ridicich a mericich systemu) velmi cenne.

Ja v tom rozhodne nevidim zadny prinos v tom, ze by takova komunikace
byla spolehlivejsi. Mozna je o trochu jednodussi pro UB lidi, mozna je
pomalejsi, ale rozhodne neni spolehlivejsi.

Petr Zahradnik, pocitacovy expert

==========================================================
Petr Zahradnik, Computer Laboratory
Obvodova 740/14, 400 07 Usti nad Labem
telefon: 475 501 627, mobil: 602 409 601, fax: 475 511 338
web: http://www.clexpert.cz, e-mail: clexpert@clexpert.cz
ICQ: 21215917, MSN: clexpert@clexpert.cz
==========================================================


Odpovedá: Jiri Foldyna

12. 8. 2004 23:29

> ak tym "klikacim sestavovanim" myslis programovanie udalosti,
> tak (nielen) vo Windowsoch to odjakziva tak fungovalo a funguje
> (vitaj vo svete udalostami riadeneho programovania).

Diky za uvitani, event driven programming je hezke a elegantni reseni
kliknuti na tlacitko  
Nechapej mne spatne, ale svet Windows neni realny svet. Je mi celkem fuk,
jestli se pri nacitani WEBove stranky pouzivaji udalosti nebo ne, pokud se
stranka nenacte, zkusim to znovu nebo se na to vykaslu (jako uzivatel). Toto
ale neni metoda, kterou bys mohl pouzit ve chvili, kdy na spravne funkci
komunikace opravdu zalezi.

> Mozno namiesto vzletnych reci o kvalifikovanych analytikoch, by
> si tu mohol popisat lepsi system, kde je to robene inac, teda lepsie
> (ze by MS DOS? ale aj tam som si programoval seriovu komunikaciu
> s preruseniami ;-( ). Rad sa poucim. Ja uz som tu sam navrhoval urobit
> ovladanie mysi timeoutami pre tych, co su na udalosti
> alergicki ale nejak
> sa tu zatial nestretlo s priaznivou odozvou.

Pro tebe to jsou mozna vzletne reci, ale spis mozna tomu jen proste
nerozumis. Nejsem zadny pedagog, a na to, abych poucoval vseznalky, jsem uz
dost stary.

> > fungujicich programu. Lukas je jeden z mala, kteri chapou,
> ze udalost
> > startuje nejaky proces, tedy ze neni entitou sama o sobe, a ze jeji
> obsluha
> > (lhostejno zda na urovni driveru, wrapperu API funkce nebo eventu v
> > aplikaci) NEPOSTACUJE ke kompletnimu reseni komunikacni ulohy. Proto
>
> mojej mysi to nastastie uplne POSTACUJE

Pokud mas pocit, ze seriova komunikace stoji a pada s ovladanim mysi, pak
zkus pouvazovat o zpetne vazbe - neboli polopaticky - potrebuje mys vedet,
jestli udaje o jeji poloze nekdo prevzal, nebo ji to je sumafuk ? Co se
stane, kdyz nahodou par zprav nedojde ? Kulove, ze...

> tak navrhujem "zabalit" aj eventy vsetkych Delphi komponentov,
> ked uz tu mame to nove, spolahlive riesenie komunikacie

Proc, smim-li se zeptat ? Obsluhu stisknuti tlacitka povazujes za seriovou
komunikaci ?

Zdravim

Jiri Foldyna



Odpovedá: Erik Salaj, Winsoft

13. 8. 2004 0:50

> Diky za uvitani, event driven programming je hezke a elegantni reseni
> kliknuti na tlacitko  
> Nechapej mne spatne, ale svet Windows neni realny svet. Je mi celkem fuk,

mozno je ten svet Windows imaginarny  

> jestli se pri nacitani WEBove stranky pouzivaji udalosti nebo ne, pokud se
> stranka nenacte, zkusim to znovu nebo se na to vykaslu (jako uzivatel).
Toto
> ale neni metoda, kterou bys mohl pouzit ve chvili, kdy na spravne funkci
> komunikace opravdu zalezi.

radsej by si mohol povedat ako teda inac treba tie stranky v browseri
otvarat,
ked na spravnej funkcii komunikacie zalezi

> Pro tebe to jsou mozna vzletne reci, ale spis mozna tomu jen proste
> nerozumis. Nejsem zadny pedagog, a na to, abych poucoval vseznalky, jsem
uz
> dost stary.

takze "skutek utek" ked prislo na lamanie chleba

> Pokud mas pocit, ze seriova komunikace stoji a pada s ovladanim mysi, pak
> zkus pouvazovat o zpetne vazbe - neboli polopaticky - potrebuje mys vedet,
> jestli udaje o jeji poloze nekdo prevzal, nebo ji to je sumafuk ? Co se
> stane, kdyz nahodou par zprav nedojde ? Kulove, ze...

a co tak priamo v obsluhe udalosti mysi spetne oznamit, ze som
tie udaje prevzal? Co je na tom nespolahlive?

> > tak navrhujem "zabalit" aj eventy vsetkych Delphi komponentov,
> > ked uz tu mame to nove, spolahlive riesenie komunikacie
>
> Proc, smim-li se zeptat ? Obsluhu stisknuti tlacitka povazujes za seriovou
> komunikaci ?

no predpokladal som, ze to "spoloahlive" riesenie seriovej komunikacie
bude mozne zobecnit aj mimo seriovej komunikacie. A namiesto
eventov budeme mat thready a timeouty a budeme volat nejake
blokovacie procedury. Napr. pre to tlacitko urobime tento spolahlivy
thread:

procedure TThreadTlacitko.Execute;
var Stlacenia: String;
begin
  Timeout := 10000; // cakame max 10 sekund

  Koniec := False;
  while not Koniec do
    try
      Stlacenia := NacitajStlacenia(10); // 10 stlaceni naraz (aby sme
prilis nezatazili system extra zistovanim kazdeho stlacenia tlacitka)

      // hura, mame ich
      Koniec := True;

      Synchronize(DajUdajeAplikacii(Stlacenia)); // nejako to
zosynchronizujeme a posleme programu, alebo
co s tymi stlaceniami teraz urobime?
    except
       on ETimeout: // este ich nemame nacitane tak pozrime, ci este nas
thread vobec treba
         if KoniecAplikacie then
           Exit;
    end
end;

Erik


Odpovedá: Jiri Foldyna

13. 8. 2004 0:52

> > Asi takto - kazdy, kdo nekdy resil problem provozu 7x24 s error
> > recovery bez zasahu obsluhy, vi, ze se bez synchronizace komunikace
> > neobejde. Proste komunikacni session v techto pripadech zacit muze v
> > podstate kdykoli, ale skoncit MUSI podle definovanych pravidel.
>
> Ja jsem asi natvrdlej. Ja porad nechapu, kde je problem toto resit
> pomoci nedoprasene asynchronni komunikace, ktera vyvolava udalosti.

Nevim, co je to nedoprasena asynchronni komunikace...

> > Prakticky vzdy se pouziva detekce chyb nedodrzenim casovani
> > protokolu, uz proto, ze nedodrzeni casovani signalizuje bud chybu v
> > algoritmu nebo nepredpokladany stav systemu, coz je u solidne
> > resenych systemu s vysokou pozadovanou spolehlivosti vzdy duvod ke
> > zvyseni ostrazitosti. Tyto technologie (synchronizace komunikace)
> > nejsou nijak zvlast obtizne implementovatelne, pouze vyzaduji
> > schopnost abstraktniho a paralelniho uvazovani pri analyze a navrhu
> > systemu. To muze byt pro mene kvalifikovane analytiky problem, avsak
> > nepochopeni problemu a metodiky reseni jeste nediskvalifikuje
> > metodu.
>
> Stale jsem asi natvrdlej - takze jako chces tim rict, ze kdyz je nekdo
> tak tupej, ze neumi obslouzit udalost, ale zato umi zavolat metodu a
> cekat, jestli proces z ni vyleze nebo nevyleze, tak ma delat aplikace
> pro provoz 24x7? Pekne dekuji.

Ne.
Prvni casti chci rict, ze nedodrzeni casovani protokolu muze byt
kvalifikovano jako chybovy stav. Pokud budes pouze reagovat na udalosti
(asynchronne, bez casovych udaju), na chybu neprijdes.
Druhou casti chci rict to, ze kdyz je nekdo tak tupej, ze umi uvazovat pouze
v intencich obsluhy udalosti, tak se nema sr..t do aplikaci vyzadujicich
vysokou spolehlivost.
Treti casti chci rict to, ze je vyhodne zvladnout obtiznou problematiku,
protoze pak mi jednodussi problemy daji mene prace.

> > Spousta lidi (i v teto konferenci) uvazuje pouze v dimenzich
> > klikaciho sestavovani jakz takz fungujicich programu.
>
> Tak ti jako maji delat ty aplikace 24x7? Nebo co jsi tim chtel rici?

Nikoli, ti by pri vyvoji aplikaci tohoto typu asi nebyli zvlastnim prinosem.
Chci tim rict, ze poskladat dohromady udalostma rizenou aplikaci z Delphi
komponent nevyzaduje zadnou zvlastni kvalifikaci.

> > Lukas je jeden z mala, kteri chapou, ze udalost startuje nejaky
> > proces, tedy ze neni entitou sama o sobe, a ze jeji obsluha
> > (lhostejno zda na urovni driveru, wrapperu API funkce nebo eventu v
> > aplikaci) NEPOSTACUJE ke kompletnimu reseni komunikacni ulohy. Proto
> > povazuji SYNASER za prinosny pristup k reseni komunikace pomoci
> > RS-232 na PC uz tim, ze se snazi do svych funkci zabalit krome
> > proste obsluhy udalosti i navazne cinnosti, nezbytne ke spolehlivemu
> > reseni komunikace. To je alespon meho pohledu (mozna deformovaneho
> > lety prace v oblasti ridicich a mericich systemu) velmi cenne.
>
> Ja v tom rozhodne nevidim zadny prinos v tom, ze by takova komunikace
> byla spolehlivejsi. Mozna je o trochu jednodussi pro UB lidi, mozna je
> pomalejsi, ale rozhodne neni spolehlivejsi.

Tak jeste jednou - programovani asynchronni komunikace je podstatne
jednodussi nez programovani synchronni komunikace. Kdo je schopen napsat a
odladit dlouhodobe fungujici synchronni komunikaci, zvladne levou zadni i
trivialni ulohy typu vytocit cislo na modemu apod. Opacne to rozhodne
neplati. A pro usnadneni TEHLE prace se SYNASER naramne hodi.

> Petr Zahradnik, pocitacovy expert

Zdravim

Jiri Foldyna



Odpovedá: Petr Fejfar

13. 8. 2004 0:56

Petr Zahradnik wrote:

> Ja v tom rozhodne nevidim zadny prinos v tom, ze by takova komunikace
> byla spolehlivejsi. Mozna je o trochu jednodussi pro UB lidi, mozna je
> pomalejsi, ale rozhodne neni spolehlivejsi.

Ne ze bych byl stoupencem blocking komunikaci, ale s tou spolehlivosti bych
nebyl tak kategoricky, protoze jestlize je jednodussi pro UB,
meli by v ni nasekat take mene chyb a tudiz takova aplikace by
mela byt spolehlivejsi  


Muj pohled na blocking/non-blocking komunikace:

Komunikacni protokoly jsou obvykle definovany pomoci prechodovych
nebo sekvencnich ev. kolaboracnich diagramu. Primocary prepis logiky
z techto diagramu do proceduralniho jazyka vede k BLOCKING implementaci.

Aby bylo mozne tuto logiku poustet po castech v kontextu nejake event,
je nutne ji doplnit o zapamatovani/obnovovani stavu - Jackson pro to zavedl
pojem Inverze programu.

Ale protoze vetsina programatoru pracuje intuitivne, tak zpravidla michaji
kod
invertujici program s logikou protokolu a vysledna implementace se stava
mene prehlednou a hur udrzovatelnou.

IMHO *jedina* vyhoda blocking implementace je nezamlzena logika protokolu
a proto je zrejme oblibenejsi nez non-blocking.


Pak uz nasleduji jen nevyhody:

- u rady aplikaci blocking pristup musi
    a) hledat kompromis mezi max. timeoutem blocking operace
        a nejkratsi pozadovanou doby odezvy napr. na zotaveni po chybe
    b) nebo si vypomahat pollingem
- pokud protokol pracuje s nevyzadanymi daty (napr. zminovany RING), tak
    a) i pri blocking pristupu zavest eventy  
    b) zase si vypomoci pollingem zvysujicim overhead

Protoze non-blocking implementace takova omezeni nema,
je IMHO non-bloking implementace jednoznacne vhodnejsi
a to zejmena v mission critical aplikacich.


pf


Odpovedá: Petr Zahradnik

13. 8. 2004 1:20

Puvodni zprava ze dne 13.8.2004:

> Prvni casti chci rict, ze nedodrzeni casovani protokolu muze byt
> kvalifikovano jako chybovy stav. Pokud budes pouze reagovat na
> udalosti (asynchronne, bez casovych udaju), na chybu neprijdes.

Asynchronni zpracovani a casovani se vzajemne nevylucuji. Stejne jako
ja mohu napriklad pracovat, zatimco cekam na udalost, ze nekdo zavola
telefonem, a zaroven mam zapnuty budik a ten mi zapipa, ze uz dlouho
nikdo nevolal, tak pocitac to take dokaze. Asynchronne.

> Druhou casti chci rict to, ze kdyz je nekdo tak tupej, ze umi
> uvazovat pouze v intencich obsluhy udalosti, tak se nema sr..t do
> aplikaci vyzadujicich vysokou spolehlivost.

Ehm. Bavime se tu o komunikaci. Takze chces tim rici, ze kdo
asynchronni komunikaci ovlada asynchronne a pouziva tedy napriklad
komponenty Async Professional, je takovej dement a nema se s...t do
toho, co ty udelas se SynaSer? Nooo... to je odvazne tvrzeni.

> Treti casti chci rict to, ze je vyhodne zvladnout obtiznou
> problematiku, protoze pak mi jednodussi problemy daji mene prace.

Jakou obtiznou problematiku? Co zase to ma s problematikou?

> Nikoli, ti by pri vyvoji aplikaci tohoto typu asi nebyli zvlastnim
> prinosem. Chci tim rict, ze poskladat dohromady udalostma rizenou
> aplikaci z Delphi komponent nevyzaduje zadnou zvlastni kvalifikaci.

Obavam se, ze poskladani komponent s jakymisi udalostmi je neco zcela
odlisneho od asynchronni komunikace. Ne nekdo umi udelat udalost
tlacitka, to nema s tematem nic spolecneho.

> Tak jeste jednou - programovani asynchronni komunikace je podstatne
> jednodussi nez programovani synchronni komunikace.

Synchronni komunikace je hlavne neco zcela jineho nez zeserializovana
asynchronni komunikace. Vazne tedy nevim, o cem mluvis.

> Kdo je schopen napsat a odladit dlouhodobe fungujici synchronni
> komunikaci, zvladne levou zadni i trivialni ulohy typu vytocit cislo
> na modemu apod. Opacne to rozhodne neplati. A pro usnadneni TEHLE
> prace se SYNASER naramne hodi.

Ty si koukam pletes pojmy. Asynchronni seriova komunikace zustane
stale asynchronni, at s tim udelas cokoliv. Ze si to v aplikacni
vrstve upravis a zeserializujes, aby se ti protokol lepe programoval,
to je tvoje vec. Naopak slozitejsi je pomoci udalosti spravne udelat
protokol. Pro cloveka, ktery umi programovat, neni problem udelat
dlouhodobe fungujici asynchronni komunikaci zalozenou na udalostech,
zrovna jako zalozenou na blokovani.

A znovu opakuji - to stale neni a nikdy nebude zadna synchronni
komunikace.

Petr Zahradnik, pocitacovy expert

==========================================================
Petr Zahradnik, Computer Laboratory
Obvodova 740/14, 400 07 Usti nad Labem
telefon: 475 501 627, mobil: 602 409 601, fax: 475 511 338
web: http://www.clexpert.cz, e-mail: clexpert@clexpert.cz
ICQ: 21215917, MSN: clexpert@clexpert.cz
==========================================================



Odpovedá: Petr Zahradnik

13. 8. 2004 1:13

Puvodni zprava ze dne 13.8.2004:

> Ne ze bych byl stoupencem blocking komunikaci, ale s tou
> spolehlivosti bych nebyl tak kategoricky, protoze jestlize je
> jednodussi pro UB, meli by v ni nasekat take mene chyb a tudiz
> takova aplikace by mela byt spolehlivejsi  

Ano, s tim lze souhlasit   I kdyz ten UB v tom nadela binec  

> Protoze non-blocking implementace takova omezeni nema, je IMHO
> non-bloking implementace jednoznacne vhodnejsi a to zejmena v
> mission critical aplikacich.

Ano, s tim take souhlasim.

Petr Zahradnik, pocitacovy expert

==========================================================
Petr Zahradnik, Computer Laboratory
Obvodova 740/14, 400 07 Usti nad Labem
telefon: 475 501 627, mobil: 602 409 601, fax: 475 511 338
web: http://www.clexpert.cz, e-mail: clexpert@clexpert.cz
ICQ: 21215917, MSN: clexpert@clexpert.cz
==========================================================



Odpovedá: Lukas Gebauer

13. 8. 2004 7:32

> IMHO *jedina* vyhoda blocking implementace je nezamlzena logika
> protokolu a proto je zrejme oblibenejsi nez non-blocking.
>
> Pak uz nasleduji jen nevyhody:
>
> - u rady aplikaci blocking pristup musi
> a) hledat kompromis mezi max. timeoutem blocking operace
> a nejkratsi pozadovanou doby odezvy napr. na zotaveni po chybe
> b) nebo si vypomahat pollingem
> - pokud protokol pracuje s nevyzadanymi daty (napr. zminovany RING),
> tak
> a) i pri blocking pristupu zavest eventy  
> b) zase si vypomoci pollingem zvysujicim overhead

A ted ta sladka pointa na zaver... v pripade Synaseru je ten overhead
velmi maly, v praxi nekolik malo instrukci za vterinu, nebo dokonce i
za nekolik vterin! Je to overhead, ktery je v praxi opravdu obtizne
meritelny, a s neohrabanymi merici zatizeni, jako je taskmanager, ti
to ani nehne.

Me to prijde jako velmi dobra cena za mnohem prehlednejsi kod (a
tudiz i mnohem snaze pochopitelnejsi a udrzovatelnejsi kod).




--
Lukas Gebauer.

E-mail: gebauerl@mlp.cz
http://www.ararat.cz/synapse/ - Ararat Synapse - TCP/IP Lib.


Odpovedá: Petr Fejfar

13. 8. 2004 9:42

Lukas Gebauer wrote:

> A ted ta sladka pointa na zaver... v pripade Synaseru je ten overhead
> velmi maly, v praxi nekolik malo instrukci za vterinu, nebo dokonce i
> za nekolik vterin!

V okamziku, kdy ta nevyzadana data nebudou mit povahu prosteho indikatoru
jako napr. RING, tak je budes muset prinejmensim strkat nekam do fronty
a zase je z ni tahat. No a to bude o trochu vice nez malo instrukci, ale
budiz  

> Me to prijde jako velmi dobra cena za mnohem prehlednejsi kod (a
> tudiz i mnohem snaze pochopitelnejsi a udrzovatelnejsi kod).

Jak psal uz PZ, ani pri rucni transkripci protokolu te nic nenuti doprasit
non-blocking implementaci tak, ze bude mene prehledna.

Jen to chce trochu teoreticke prupravy a mene intuitivnich postupu  


pf


Odpovedá: Lukas Gebauer

13. 8. 2004 10:34

> V okamziku, kdy ta nevyzadana data nebudou mit povahu prosteho
> indikatoru jako napr. RING, tak je budes muset prinejmensim strkat
> nekam do fronty a zase je z ni tahat. No a to bude o trochu vice nez
> malo instrukci, ale budiz  

Ale to v pripade udalostmi rizeneho prijimani dat musis delat take!
Proto jsem tuto zatez navic nepocital, protoze ji musis udelat vzdy,
lhosteno na pouzitem rezimu komunikace.

Kdyz ti prijde z portu udalost, ze ti prisly dva baty 'RI', tak si to
stejne musis dat nekam do fronty, a pockat, dokud nebudes mit k
dispozici cely 'RING', ne?

Tedy ja demonstroval skutecnou zatez navic, ktera je skutecne dana
povahou blokujici komunikace. Tato zatez navic tu skutecne je, jen
jsem se ja konkretne jak snazil o to, aby tato zatez byla tak mala,
aby pro jeji zanedbatelnost nebyla nikomu naobtiz.

> Jak psal uz PZ, ani pri rucni transkripci protokolu te nic nenuti
> doprasit non-blocking implementaci tak, ze bude mene prehledna.
> Jen to chce trochu teoreticke prupravy a mene intuitivnich postupu  

Totez lze rict i obracene... v pripade blocking rezimu te nic nenuti
udelat to zprasene tak, aby to chodilo hure nez non-blocking.



--
Lukas Gebauer.

E-mail: gebauerl@mlp.cz
http://www.ararat.cz/synapse/ - Ararat Synapse - TCP/IP Lib.


Odpovedá: Jiri Foldyna

13. 8. 2004 11:32

> > Pro tebe to jsou mozna vzletne reci, ale spis mozna tomu jen proste
> > nerozumis. Nejsem zadny pedagog, a na to, abych poucoval
> vseznalky, jsem
> uz
> > dost stary.
>
> takze "skutek utek" ked prislo na lamanie chleba

Skutek utek ? Lamani chleba ? Hezke fraze... To, ze ti nejsou jasne
evidentni veci neznamena, ze ti je nekdo musi vysvetlovat, aby ti dokazal,
ze se mylis.

> > Pokud mas pocit, ze seriova komunikace stoji a pada s
> ovladanim mysi, pak
> > zkus pouvazovat o zpetne vazbe - neboli polopaticky -
> potrebuje mys vedet,
> > jestli udaje o jeji poloze nekdo prevzal, nebo ji to je
> sumafuk ? Co se
> > stane, kdyz nahodou par zprav nedojde ? Kulove, ze...
>
> a co tak priamo v obsluhe udalosti mysi spetne oznamit, ze som
> tie udaje prevzal? Co je na tom nespolahlive?

A mys bude cekat, az ji potvrzeni zasles ? A do te doby prestane posilat
udaje o poloze ? Nebo si bude zpravy cislovat a evidovat, jestli na ty
zpravy dostala potvrzeni ? Hmmm, velmi sofistikovane reseni trivialni ulohy
 

> > > tak navrhujem "zabalit" aj eventy vsetkych Delphi komponentov,
> > > ked uz tu mame to nove, spolahlive riesenie komunikacie
> >
> > Proc, smim-li se zeptat ? Obsluhu stisknuti tlacitka
> povazujes za seriovou
> > komunikaci ?
>
> no predpokladal som, ze to "spoloahlive" riesenie seriovej komunikacie
> bude mozne zobecnit aj mimo seriovej komunikacie. A namiesto
> eventov budeme mat thready a timeouty a budeme volat nejake
> blokovacie procedury. Napr. pre to tlacitko urobime tento spolahlivy
> thread:

Evidentne chybny predpoklad, zahonky ruzi se prece taky neokopavaji
bagrem...

> procedure TThreadTlacitko.Execute;
> var Stlacenia: String;
> begin
> Timeout := 10000; // cakame max 10 sekund
>
> Koniec := False;
> while not Koniec do
> try
> Stlacenia := NacitajStlacenia(10); // 10 stlaceni naraz (aby sme
> prilis nezatazili system extra zistovanim kazdeho stlacenia tlacitka)
>
> // hura, mame ich
> Koniec := True;
>
> Synchronize(DajUdajeAplikacii(Stlacenia)); // nejako to
> zosynchronizujeme a posleme programu, alebo
> co s tymi stlaceniami teraz urobime?
> except
> on ETimeout: // este ich nemame nacitane tak pozrime,
> ci este nas
> thread vobec treba
> if KoniecAplikacie then
> Exit;
> end
> end;
>
> Erik

To muselo dat prace, vymyslet takovou blbost...

Zdravim

Jiri Foldyna


Odpovedá: Jiri Foldyna

13. 8. 2004 11:54

> Asynchronni zpracovani a casovani se vzajemne nevylucuji. Stejne jako
> ja mohu napriklad pracovat, zatimco cekam na udalost, ze nekdo zavola
> telefonem, a zaroven mam zapnuty budik a ten mi zapipa, ze uz dlouho
> nikdo nevolal, tak pocitac to take dokaze. Asynchronne.

Asynchronni zpracovani a casovani se navzajem vylucuje. Jakmile do
komunikace zavedes casove znacky, znamena to, komuikace prestane byt
asynchronni. Je pritom jedno, jestli za casove znacky povazujes hodinovy
signal UARTu, nebo pipnuti budiku.

> > Tak jeste jednou - programovani asynchronni komunikace je podstatne
> > jednodussi nez programovani synchronni komunikace.
>
> Synchronni komunikace je hlavne neco zcela jineho nez zeserializovana
> asynchronni komunikace. Vazne tedy nevim, o cem mluvis.

Z toho si nic nedelej, to je vzajemne  

> Ty si koukam pletes pojmy. Asynchronni seriova komunikace zustane
> stale asynchronni, at s tim udelas cokoliv. Ze si to v aplikacni
> vrstve upravis a zeserializujes, aby se ti protokol lepe programoval,
> to je tvoje vec. Naopak slozitejsi je pomoci udalosti spravne udelat
> protokol. Pro cloveka, ktery umi programovat, neni problem udelat
> dlouhodobe fungujici asynchronni komunikaci zalozenou na udalostech,
> zrovna jako zalozenou na blokovani.
> A znovu opakuji - to stale neni a nikdy nebude zadna synchronni
> komunikace.

Pokud uvazujes v intencich 1 zprava = 1 znak precteny nebo odeslany z/do
UARTu, pak mas pravdu. Pokud potrebujes poslat obousmerne vetsi mnozstvi
znaku, na jejichz casove posloupnosti zavisi smysl komunikace, pak pravdu
nemas.

Preji hezky vikend.

Zdravim

Jiri Foldyna


Odpovedá: Erik Salaj, Winsoft

13. 8. 2004 12:13

> Skutek utek ? Lamani chleba ? Hezke fraze... To, ze ti nejsou jasne
> evidentni veci neznamena, ze ti je nekdo musi vysvetlovat, aby ti dokazal,
> ze se mylis.

ale da to chapat aj tak, ze to jednoducho nevies vysvelit
a vyhovaras sa. Tvoje filozoficke uvahy o svete Windows
su mi na ... . Ukaz mi radsej riesenie, ak ho poznas.
A porovnajme rozne riesenia.

>To muselo dat prace, vymyslet takovou blbost...

no vidis a ja urobil tu pracu aby som ukazal, ze udalosti
maju svoj vyznam (nielen pri seriovej komunikacii ale
aj inde). Nefilozofoval som o "nerealnom" svete Windows
ale napisal kus kodu a mozme porovnat. A sam si
prisiel na to (gratulujem), ze tento "alternativny" sposob
je v tomto pripade blbost.

Erik



Odpovedá: Erik Salaj, Winsoft

13. 8. 2004 12:23

> Asynchronni zpracovani a casovani se navzajem vylucuje. Jakmile do
> komunikace zavedes casove znacky, znamena to, komuikace prestane byt
> asynchronni. Je pritom jedno, jestli za casove znacky povazujes hodinovy
> signal UARTu, nebo pipnuti budiku.

no by bolo super, keby som si mohol na asynchronnej komunikacii
zadefinovat 3 casove znacky za den a mal z toho zrazu komunikaciu
synchronnu. Ale to je mozne asi len v tom imaginarnom svete,
v realnom urcite nie  .

Erik


Odpovedá: Jiri Foldyna

13. 8. 2004 12:31

> ale da to chapat aj tak, ze to jednoducho nevies vysvelit
> a vyhovaras sa. Tvoje filozoficke uvahy o svete Windows
> su mi na ... . Ukaz mi radsej riesenie, ak ho poznas.
> A porovnajme rozne riesenia.

Je mi celkem jedno, jak si to vysvetlis   Pokud chces poradit, zeptej se
na konkretni vec, kdyz budu umet, poradim. Pokud potrebujes vyresit
konkretni problem, sem s nim, zkusime se dohodnout na cene a terminu. Pokud
chces vest akademicke diskuse, najdi si nekoho jineho.

> >To muselo dat prace, vymyslet takovou blbost...
>
> no vidis a ja urobil tu pracu aby som ukazal, ze udalosti
> maju svoj vyznam (nielen pri seriovej komunikacii ale
> aj inde). Nefilozofoval som o "nerealnom" svete Windows
> ale napisal kus kodu a mozme porovnat. A sam si
> prisiel na to (gratulujem), ze tento "alternativny" sposob
> je v tomto pripade blbost.

Velmi cenny prispevek, zejmena k tematu Synaser a prace s nim  

Preji prijemny vikend.

Zdravim

Jiri Foldyna


Odpovedá: Petr Zahradnik

13. 8. 2004 13:05

Puvodni zprava ze dne 13.8.2004:

>> Asynchronni zpracovani a casovani se vzajemne nevylucuji. Stejne jako
>> ja mohu napriklad pracovat, zatimco cekam na udalost, ze nekdo zavola
>> telefonem, a zaroven mam zapnuty budik a ten mi zapipa, ze uz dlouho
>> nikdo nevolal, tak pocitac to take dokaze. Asynchronne.

> Asynchronni zpracovani a casovani se navzajem vylucuje. Jakmile do
> komunikace zavedes casove znacky, znamena to, komuikace prestane byt
> asynchronni. Je pritom jedno, jestli za casove znacky povazujes
> hodinovy signal UARTu, nebo pipnuti budiku.

To pochopitelne neni pravda, co mi tu vypravis. Ze v ramci asynchronni
komunikace probehne neco v ramci urciteho casoveho sledu, to rozhodne
neznamena, ze se jedna o komunikaci synchronni. Jak jsi na to prosimte
vubec prisel?

>> A znovu opakuji - to stale neni a nikdy nebude zadna synchronni
>> komunikace.

> Pokud uvazujes v intencich 1 zprava = 1 znak precteny nebo odeslany
> z/do UARTu, pak mas pravdu. Pokud potrebujes poslat obousmerne vetsi
> mnozstvi znaku, na jejichz casove posloupnosti zavisi smysl
> komunikace, pak pravdu nemas.

Rozhodne s tebou nesouhlasim. O tom asynchronnost a synchronnost
komunikace rozhodne neni.

Petr Zahradnik, pocitacovy expert

==========================================================
Petr Zahradnik, Computer Laboratory
Obvodova 740/14, 400 07 Usti nad Labem
telefon: 475 501 627, mobil: 602 409 601, fax: 475 511 338
web: http://www.clexpert.cz, e-mail: clexpert@clexpert.cz
ICQ: 21215917, MSN: clexpert@clexpert.cz
==========================================================


Odpovedá: Jiri Foldyna

13. 8. 2004 12:53

> To pochopitelne neni pravda, co mi tu vypravis. Ze v ramci asynchronni
> komunikace probehne neco v ramci urciteho casoveho sledu, to rozhodne
> neznamena, ze se jedna o komunikaci synchronni. Jak jsi na to prosimte
> vubec prisel?
> Rozhodne s tebou nesouhlasim. O tom asynchronnost a synchronnost
> komunikace rozhodne neni.
>
> Petr Zahradnik, pocitacovy expert

Ja to vzdavam.

Zdravim

Jiri Foldyna


Odpovedá: Jan Masek

13. 8. 2004 13:58

> > To pochopitelne neni pravda, co mi tu vypravis. Ze v ramci asynchronni
> > komunikace probehne neco v ramci urciteho casoveho sledu, to rozhodne
> > neznamena, ze se jedna o komunikaci synchronni. Jak jsi na to prosimte
> > vubec prisel?
> > Rozhodne s tebou nesouhlasim. O tom asynchronnost a synchronnost
> > komunikace rozhodne neni.
> >
> > Petr Zahradnik, pocitacovy expert
>
> Ja to vzdavam.

Panove prominou, ale na tohle se fakt neda koukat.
Kazdy mate svou pravdu a hadate se (diskutujete) naprosto zbytecne  
Jeden o voze, druhy o koze a treti pro zmenu zase o necem jinem  

To, ze pletete dohromady vsechny urovne ISO modelu komunikace zrejmne nikomu
nevadi.
To, ze pletete dohromady vlastni komunikaci a jeji zpracovani zrejmne take
nikomu nevadi
To, ze mate v terminologii gulas hodny predvolebnich manifestu zrejmne opet
nikomu nevadi

Co kdyby jste si vse nejprve ujasnili a pak rozpoutali obdobny flame ale trochu
vyfutrovany
vedomostmi a ne jen domnenkami ??

Jen maly priklad - je HTTP protokol synchronni, nebo asynchronni, kdyz je
jednou prenasen
po Ethernetu a podruhe po RS232 ??? Kdo to vi odpovi  

J.Masek




Odpovedá: Petr Fejfar

13. 8. 2004 13:46

Lukas Gebauer wrote:

> Kdyz ti prijde z portu udalost, ze ti prisly dva baty 'RI', tak si to
> stejne musis dat nekam do fronty, a pockat, dokud nebudes mit k
> dispozici cely 'RING', ne?

Ja bych to nenazyval frontou, ale vstupnim bufferem, typicky kruhovym.
Ano, ten musis mit vzdy.

Ale v blocking rezimu si nekde musis jeste zapamatovat unsolicited data,
ktera jsi prijal mimo kontext probihajici blocking operace.

Uvedu dva *realne* priklady:

1. Komunikace se SMS modemem v prikazovem rezimu napr. cteni obsahu phone
booku
    se soucasnym prijmem nevyzadanych dat, coz muze vypadat klidne takto:

    ....
    AT+CPBR=<n>
    +CPBR: <n>, ......
   +CMT: <unsolicited data>
    OK
    ....

    V ramci cekani na odezvu OK/ERROR musis rozeznat prijem nevyzadanych
dat,
    odebrat je ze vstupniho bufferu a nekam si je odlozit, aby ses k nim
mohl vratit,
    az dokoncis blocking operaci. Takze oproti non-blocking rezimu je zde
navic
    prepis ze vstupniho bufferu do fronty nevyzadanych dat a nasledne cteni
    pri jejich odlozenem zpracovani + overhead fronty.

2. Protokol, ktery do prave probihajiciho packetu vklada packet s vyssi
prioritou,
    tedy <STX>......<STX>......<ETX>......<ETX> V praxi jsem se setkal s
jednou urovni vnoreni.

    Takovy protokol se v blocking rezimu *neda* obslouzit vubec, protoze
tady je nutne na vlozeny packet
    - typicky nejaky ridici povel - bezprostredne reagovat.


pf


Odpovedá: Lukas Gebauer

13. 8. 2004 14:07

> az dokoncis blocking operaci. Takze oproti non-blocking rezimu je
> zde
> navic
> prepis ze vstupniho bufferu do fronty nevyzadanych dat a nasledne
> cteni pri jejich odlozenem zpracovani + overhead fronty.

Ano, v tomto pripade ano, je to nejaka prace navic, ale toto je
pomerne specifikacka situace, ktera nenastava tak casto, aby to
principielne degradovalo vykon blocking metody. Jednoduse, ne vsechny
protokoly vubec znaji podobne situace. A i kdyz je zna, tak k
takovymto situacim nedochazi tak casto, aby to realne ohrozilo vykon
aplikace.

> 2. Protokol, ktery do prave probihajiciho packetu vklada packet s
> vyssi prioritou,
> tedy <STX>......<STX>......<ETX>......<ETX> V praxi jsem se setkal
> s
> jednou urovni vnoreni.
>
> Takovy protokol se v blocking rezimu *neda* obslouzit vubec,
> protoze tady je nutne na vlozeny packet - typicky nejaky ridici povel -
> bezprostredne reagovat.

Proc by to neslo obslouzit? Ze to jde, jsem si i prakticky vyzkousel,
viz. muj Telnet klient v Synapsi. Jde jen o to, jak moc inteligentni
kod sedi mezi tvoji aplikaci a operacnim systemem. A prave od toho tu
Synapse i Synaser jsou.  




--
Lukas Gebauer.

E-mail: gebauerl@mlp.cz
http://www.ararat.cz/synapse/ - Ararat Synapse - TCP/IP Lib.


Odpovedá: Petr Fejfar

13. 8. 2004 14:07

Lukas Gebauer wrote:

> Proc by to neslo obslouzit? Ze to jde, jsem si i prakticky vyzkousel,
> viz. muj Telnet klient v Synapsi. Jde jen o to, jak moc inteligentni
> kod sedi mezi tvoji aplikaci a operacnim systemem. A prave od toho tu
> Synapse i Synaser jsou.  

Tak mi vysvetli, jak prerusis blocking operaci a predas rizeni aplikaci,
aby reagovala na obsah vlozeneho packetu, aniz bys vyvolal event.
(ty pakety se vnoruji proto, ze neni cas cekat na jejich dovysilani)


pf


Odpovedá: Lukas Gebauer

13. 8. 2004 15:09

> Tak mi vysvetli, jak prerusis blocking operaci a predas rizeni aplikaci,
> aby reagovala na obsah vlozeneho packetu, aniz bys vyvolal event.
> (ty pakety se vnoruji proto, ze neni cas cekat na jejich dovysilani)

No, ono zalezi na tom, kde je ta operace blokujici. Ja napriklad nikdy
nevolam API operaci na cteni dat tak, aby byla blokujici. Vzdy ctu jen
data, ktera prokazatelne existuji uz prectena v systemovych bufferech.
Tim se mi beh nikdy nezablokuje na operaci cteni z API.

Model je tady takovy:
Aplikace zadava pozadavek na precteni dejme tomu kilobajtu dat. Ja ted
periodicky ctu data ze systemovych bufferu, dokud neobdrzim potrebne
mnozstvi dat. Pokud pozadovana data nejsou v bufferech, jednoduse se
uspim a necham se driverem probudit az kdyz zase nejaka nova data
prijdou. Jakmile mam vsechna pozadovana data prectena, ukoncim beh me
funkce, cimz vratim rizeni volajici aplikaci.

Diky tomu se cela operace z pohledu volajiciho programu chova jako
blokujici. Nicmene fyzicky jsou data nacitana postupne po kouskach, po
uplne stejnych kouskach, ktere jsou ti predavany v pripade eventu u non-
blocking rezimu. Tedy, mam moznost uplne stejne reagovat na vnorene
packety jako u non-blocking rezimu.

--
Lukas Gebauer.

E-mail: gebauerl@mlp.cz
WEB: http://www.ararat.cz/synapse - Synapse Delphi and Kylix TCP/IP
Library



Odpovedá: Erik Salaj, Winsoft

13. 8. 2004 17:08

This is a multi-part message in MIME format.



Odpovedá: Petr Fejfar

13. 8. 2004 17:21

Lukas Gebauer wrote:

> non- blocking rezimu. Tedy, mam moznost uplne stejne reagovat na
> vnorene packety jako u non-blocking rezimu.

Data flow mas stejny, ale co control flow?

U non-blockling rezimu vyvolas event a tim spustis kod
pro zpracovani doslych dat pres standardni
rozhrani vrstvy. Ta si zjisti, jestli uz prijala packet
a zpracuje ho beznym zpusobem.

Ovsem v pripade blocking rezimu, i kdyz rozeznas v datech vnoreny packet
uvnitr blokujici logiky operace receive, jak predas rizeni na rozhrani
vrstvy k dalsimu zpracovani?

Ocekaval bych, ze u blocking rezimu je standardni rozhrani tvoreno nejakou
blokujici
funkci RecvXXXX, ne? Takze dalsi rozhrani pro spousteni eventu?


pf


Odpovedá: Erik Salaj, Winsoft

13. 8. 2004 17:22

> Co kdyby jste si vse nejprve ujasnili a pak rozpoutali obdobny flame ale
trochu vyfutrovany
> vedomostmi a ne jen domnenkami ??

tak skusme, na webe
http://whatis.techtarget.com/definition/0,,sid9_gci213080,00.html
som nasiel tuto definiciu:

==================================================:

synchronous

In general, synchronous (pronounced SIHN-kro-nuhs, from Greek syn-, meaning
"with," and chronos, meaning "time") is an adjective describing objects or
events that are coordinated in time. In information technology, the term has
several different usages.
1) In telecommunication signaling within a network or between networks,
synchronous signals are those that occur at the same clock rate when all
clocks are based on a single reference clock. (plesiochronous signals are
almost but not quite in synchronization and asynchronous signals are those
that run from different clocks or at a different transition rate.)

2) In program-to-program communication, synchronous communication requires
that each end of an exchange of communication respond in turn without
initiating a new communication. A typical activity that might use a
synchronous protocol would be a transmission of files from one point to
another. As each transmission is received, a response is returned indicating
success or the need to resend. Each successive transmission of data requires
a response to the previous transmission before a new one can be initiated.

Synchronous program communication is contrasted with asynchronous program
communication.

==================================================:

> Jen maly priklad - je HTTP protokol synchronni, nebo asynchronni, kdyz je
jednou prenasen
> po Ethernetu a podruhe po RS232 ??? Kdo to vi odpovi  

z uvedenej definicie mi vychadza, ze je to synchronny protokol (i ked snad
trocha specificky)

Celkom dobre informacie ohladom socket programovania a kedy pouzit blocking
a kedy neblocking operacie su na
http://tangentsoft.net/wskfaq/articles/io-strategies.html .

V podstate zhrnutie tychto pristupov je tam v bode 12:

=======================
Heuristic 12: Blocking sockets are simpler, non-blocking sockets are more
powerful.
This heuristic is almost a restatement of all the above material. It just
bears repeating that, while blocking sockets are attractive for their
simplicity, you may find that their disadvantages eventually force you to
redesign your program to use some form of non-blocking sockets. This is
especially true if your program will be supporting more than one socket.
(Virtuall all server programs fall into this category.) The only reasonable
way to use multiple blocking sockets at once is to use threads, but with
non-blocking sockets, you have many more design options.

=======================

Erik


Odpovedá: Erik Salaj, Winsoft

13. 8. 2004 17:59

> Co kdyby jste si vse nejprve ujasnili a pak rozpoutali obdobny flame ale
trochu vyfutrovany
> vedomostmi a ne jen domnenkami ??

a teraz som este nasiel nieco dalsie, tiez celkom zaujimave
ohladom protokolov:

http://biomoby.org/S-MOBY/doc/TechAssessment/Protocols.html

====================================

Synchronicity

While the web is asynchronous, HTTP is a synchronous protocol.

====================================

Erik


Odpovedá: Jan Masek

13. 8. 2004 18:52

> > Jen maly priklad - je HTTP protokol synchronni, nebo asynchronni, kdyz je
> jednou prenasen
> > po Ethernetu a podruhe po RS232 ??? Kdo to vi odpovi  
>
> z uvedenej definicie mi vychadza, ze je to synchronny protokol (i ked snad
> trocha specificky)
>
> Celkom dobre informacie ohladom socket programovania a kedy pouzit blocking
> a kedy neblocking operacie su na

Ne, Ty to opravdu nechapes  
A bohuzel podle cele debaty nejsi sam. Michate do sebe fyzicke vrstvy,
transportni protokoly,
aplikacni protokoly, jejich zpracovani a to vse jeste z pohledu konkretni
platformy  

Debatujete tu o vhodnosti te ci one metodiky pro zpracovani asynchonniho
prenosu,
ale malokdo z Vas je ochoten pripustit, ze bloumate v zacarovanem kruhu

Na asynchronni lince (fyzicke vrstve) mohu mit (a casto take mam) synchronni
transportni
protokol. A to cele samozrejmne i naopak. Pro jednoduchost - TCP je synchronni
transportni
protokol, UDP je asynchronni transportni protokol. Oba pritom mohou byt
prenaseny na ruznych
synchronnich (Ethernet) ci asynchronnich (RS232) fyzickych vrstvach.

A presne toto tu michate vesele dohromady, plus do toho vnasite dalsi zmatek
vlastnim
zpracovanim v aplikaci a to vse promichavate nepresnou terminologii  

NEKDY je vhodne pouzit non-blocking zpracovani, NEKDY je vhodny opak.
Ale to vzdy zalezi na konkretnim protokolu a aplikaci. Neznam, zadny generalne
aplikovatelny uzus a to delam s nejruznejsimi komunikacemi petadvacet let
od prostych 8b MCU po 64b dela  

Proste vsichni mate v necem pravdu, tak nad cim debatujete ??

J.Masek

Odpovedá: Erik Salaj, Winsoft

13. 8. 2004 23:46

> Ne, Ty to opravdu nechapes  
>A bohuzel podle cele debaty nejsi sam. Michate do sebe fyzicke vrstvy,
transportni protokoly,
>aplikacni protokoly, jejich zpracovani a to vse jeste z pohledu konkretni
platformy  
>
> Na asynchronni lince (fyzicke vrstve) mohu mit (a casto take mam)
synchronni transportni
> protokol. A to cele samozrejmne i naopak. Pro jednoduchost - TCP je
synchronni transportni
> protokol, UDP je asynchronni transportni protokol. Oba pritom mohou byt
prenaseny na ruznych
> synchronnich (Ethernet) ci asynchronnich (RS232) fyzickych vrstvach.

a tvrdil som nieco ine? Skus tu konkretnejsie napisat,
co som nepochopil a uviedol zle. Ze sa bavime o roznych
veciach, to neznamena, ze su to nepravdy. Ved ty si tu tiez prave
uviedol (namiesal?) x-pojmov ohladom komunikacie.

Poslal som tu linky, kde su jednotlive pojmy ohladom komunikacie
vysvetlene (nie mnou, ale suhlasim s nimi, nevidel som tam nejake
nezrovnalosti) - prave preto aby sme to nemiesali. Tak ako co tu
je problem teraz rozumiet, alebo v com je problem, su tie informacie
na tych web strankach nespravne?

> NEKDY je vhodne pouzit non-blocking zpracovani, NEKDY je vhodny opak.

cely cas sa o tom bavime a cely cas tvrdim to iste. A uz ma to nebavi
citovat to tu treti krat, tak si to pohladaj v archive a presvedc sa o tom.

> Proste vsichni mate v necem pravdu, tak nad cim debatujete ??

mozno chceme vediet (a mat?) celu pravdu, nielen cast pravdy  

Erik


Odpovedá: Erik Salaj, Winsoft

14. 8. 2004 0:39

> > z uvedenej definicie mi vychadza, ze je to synchronny protokol (i ked
snad
> > trocha specificky)
> >
> > Celkom dobre informacie ohladom socket programovania a kedy pouzit
blocking
> > a kedy neblocking operacie su na
>
> Ne, Ty to opravdu nechapes  
> A bohuzel podle cele debaty nejsi sam. Michate do sebe fyzicke vrstvy,
transportni protokoly,
> aplikacni protokoly, jejich zpracovani a to vse jeste z pohledu konkretni
platformy  

no teraz ma napadlo, ze Ty si si zrejme tie dva odstavce (pre ilustraciu
su ponechane na zaciatku tohto mailu) spojil dohromady, t.j. dal do
nejakych suvislosti (ZMIESAL) a preto za tym kritizujes miesanie.

Lenze jeden odstavec je o jednom (odpoved na Tvoju
otazku ohladom HTTP) a druhy o inom (linka
na blocking/nonblocking). Lebo ten mail bol o tom,
ze su tam linky na rozne komunikacne pojmy (aby
si to mohol kazdy precitat a tie pojmy sa nemiesali).
Tak skus snad najprv pozornejsie citat maily a az
potom kritizovat. Lebo sranda je, ze presne to,
co kritizujes (teda miesanie veci) si, zda sa, sam
predviedol.

Erik



Odpovedá: Jan Masek

14. 8. 2004 7:51

> no teraz ma napadlo, ze Ty si si zrejme tie dva odstavce (pre ilustraciu
> su ponechane na zaciatku tohto mailu) spojil dohromady, t.j. dal do
> nejakych suvislosti (ZMIESAL) a preto za tym kritizujes miesanie.
>
> Lenze jeden odstavec je o jednom (odpoved na Tvoju
> otazku ohladom HTTP) a druhy o inom (linka
> na blocking/nonblocking). Lebo ten mail bol o tom,
> ze su tam linky na rozne komunikacne pojmy (aby
> si to mohol kazdy precitat a tie pojmy sa nemiesali).
> Tak skus snad najprv pozornejsie citat maily a az
> potom kritizovat. Lebo sranda je, ze presne to,
> co kritizujes (teda miesanie veci) si, zda sa, sam
> predviedol.

Ach tak je to, ma malickost opet nepochopila hloubku Tvych uvah  
Vzdyt Ty vlastne vnasis osvetu do davu nevedomych

Jednoduchou odpoved na jednoduchou otazku doplnis o neouvisejici
odkaz na jinou (byt pribuznou) tematiku. Promin, ale to mi prave pripada
jako michani jablek s hruskama  

Nezlob se, ale nemam chut, naladu ani dusevni sily vest s Tebou tuto plodnou
debatu.
Po projiti archivu konference mi je naprosto jasne, ze uznavas pouze dve
pravidla:
1) Mam vzdy pravdu
2) Pokud ne, plati bod jedna

Omlouvam se (zivot me naucil pokore) a uznavam, oproti ostatnim,
Ty mas VZDY a ve VSEM pravdu.
Ja se vrati zpet ke svym chybam, polopravdam a kompromisum  

J.Masek


Odpovedá: Lukas Gebauer

16. 8. 2004 8:54

> Ovsem v pripade blocking rezimu, i kdyz rozeznas v datech vnoreny
> packet uvnitr blokujici logiky operace receive, jak predas rizeni na
> rozhrani vrstvy k dalsimu zpracovani?
>
> Ocekaval bych, ze u blocking rezimu je standardni rozhrani tvoreno
> nejakou blokujici funkci RecvXXXX, ne? Takze dalsi rozhrani pro
> spousteni eventu?

Ano, na ty vnorena data je tam event. Zatimco bezna data protokolu
jsou obsluhovana klasicky blokujicim zpusobem, ony 'out-of-band' data
jsou obsluhovany eventem. Ale netreba tady dlouze popisovat jak to
funguje, kdyz si to muzes okoukat z toho Telnetu v Synapsi, ne?



--
Lukas Gebauer.

E-mail: gebauerl@mlp.cz
http://www.ararat.cz/synapse/ - Ararat Synapse - TCP/IP Lib.


Odpovedá: Petr Fejfar

16. 8. 2004 8:20

Lukas Gebauer wrote:

> Ano, na ty vnorena data je tam event. Zatimco bezna data protokolu
> jsou obsluhovana klasicky blokujicim zpusobem, ony 'out-of-band' data
> jsou obsluhovany eventem. Ale netreba tady dlouze popisovat jak to
> funguje, kdyz si to muzes okoukat z toho Telnetu v Synapsi, ne?

Me je jasne, jak to funguje - ja to pisu jako ukazku nevhodnosti
blocking obsluhy protokolu tohoto typu - kdyz uz *musis* udelat event,
tak to vsechno muzes obsluhovat v ni, ne?  

pf


Odpovedá: Lukas Gebauer

16. 8. 2004 8:27

> Me je jasne, jak to funguje - ja to pisu jako ukazku nevhodnosti
> blocking obsluhy protokolu tohoto typu - kdyz uz *musis* udelat event,
> tak to vsechno muzes obsluhovat v ni, ne?  

Muzes... ale nemusis. Proc kvuli par 'OOB' dat ztracet tu zakladni
vyhodu blocking komunikace, zvlast kdyz v tomto konkretnim priapde
ona komuniacni knihovna za tebe odvede hromady prace, ktere bys jinak
musel delat vlastnimi silami ve zpracovani tech eventu?

--
Lukas Gebauer.

E-mail: gebauerl@mlp.cz
http://www.ararat.cz/synapse/ - Ararat Synapse - TCP/IP Lib.